Viewing Firewall States in the GUI¶
The page at Diagnostics > States in the GUI contains a listing of the firewall state table contents. Figure Example States shows a sample of the output displayed by the GUI.
The page displays several columns of information for each state table entry, each with important information:
The interface to which the state is bound. This is the interface through which the packet initially entered or exited the firewall.
The protocol of the traffic that created the state, such as TCP, UDP, ICMP, or ESP.
- Source and Destination
This column is in two parts, first the source, then an arrow indicating direction, and then the destination.
The source and destination may also have a port number listed if the protocol in question uses ports.
In cases where NAT is applied (outbound NAT, port forwards, or 1:1 NAT), the address is shown both before and after NAT has been applied. For NAT such as outbound NAT which translates the source, the source section displays the translated source and the original source inside parenthesis. For NAT types that translate the destination, such as port forwards, the destination section shows the translated destination and the original destination in parenthesis.
The current status of the connection being tracked by this state entry.
The specific values vary depending on the protocol. For example, TCP has many more state types than UDP or other connectionless protocols. See Interpreting States for more detail.
The entry in this column contains two parts separated by a colon. The first part is the connection state for the source side, and the second part is the connection state for the destination side.
The number of packets the firewall has observed which match the state from the source and destination sides.
The total size of packets the firewall has observed which match the state from the source and destination sides.
The icon at the end of each row removes individual states.
The State Filter panel enables quick searching of the state table contents to find items of interest.
To search for a state:
Select a specific Interface in the State Filter panel or leave it on all to match all interfaces.
Enter a Filter Expression which is a simple string of text to match exactly in the entry. This field does not support regular expressions.
Click Filter to locate the results.
The search process attempts to match text across all columns and it only displays entries matching the search parameters.
Searching for an IP address or subnet will also present a Kill States button which, when clicked, will remove all states originating from or going to the entered IP address or subnet.
For systems with extraordinarily large state tables, filtering can be a requirement. The Require State Filter option on General Configuration Options prevents the firewall from displaying state table content until the user filters the state table output. This prevents the page from attempting to display too much data.
The State column for each state table entry provides information necessary to determine exactly what is happening with the connection. Each state entry contains two values with a colon between them, marking which value represents the state of the source (left), and which represents the destination (right).
A few of the most common state types are:
For TCP connections this indicates that the side showing this state sent a TCP SYN packet attempting to start a connection handshake.
For TCP connections the side with this status considers the connection closed, or the firewall has not received any traffic.
A TCP connection is considered fully established by this side.
A TCP connection is in the process of closing and finishing up.
The firewall has not received any packets that match the state from this side.
The firewall has observed a single packet on this state from this side.
The firewall has observed multiple packets on this state from this side.
Common pairings frequently found in the state table include:
A fully established two-way TCP connection.
The side showing SYN_SENT has sent a TCP SYN packet but no response has been received from the far side. Often this is due to the packet not reaching its destination, or being blocked along the way.
Similar to the above, but for UDP and other connectionless protocols. No response has been received from the destination side.
For UDP and other connectionless protocols, commonly observed with DNS where the client sends one packet but receives a large response in multiple packets.
For UDP and other connectionless protocols, there are multiple packets in both directions, which is normal for a fully operational UDP connection.
Indicates that there is no state level data. Typically only found on ICMP states, since ICMP does not have state levels like other protocols.