Viewing the Firewall Logs¶
The firewall creates log entries for each rule configured to log and for the default deny rule. There are several ways to view these log entries, each with varying levels of detail. There is no clear “best” method since it depends on the preferences and skill level of the firewall administrators, though using the GUI is the easiest method.
The logging behavior of the default deny rules and other internal rules can be controlled using the Settings tab under Status > System Logs. See Changing Log Settings for details.
Like other logs in pfSense, the firewall logs only keep a certain number of records using the binary circular log format, clog. If the needs of an organization require a permanent record of firewall logs for a longer period of time, see System Logs for information on copying these log entries to a syslog server as they happen.
Viewing in the WebGUI¶
The firewall logs are visible in the WebGUI at Status > System Logs, on the Firewall tab. From there, the logs can be viewed as a parsed log, which is easier to read, or as a raw log, which contains more detail. There is also a setting to show these entries in forward or reverse order. If the order the log entries being displayed is unknown, check the timestamp of the first and last lines, or check Changing Log Settings for information on how to view and change these settings.
The parsed WebGUI logs, seen in Figure Example Log Entries Viewed From The WebGUI, are in 6 columns: Action, Time, Interface, Source, Destination, and Protocol.
|Action:||Shows what happened to the packet which generated the log entry (e.g. pass or block)|
|Time:||The time that the packet arrived.|
|Interface:||Where the packet entered the firewall.|
|Source:||The source IP address and port.|
|Destination:||The destination IP address and port.|
|Protocol:||The protocol of the packet, e.g. ICMP, TCP, UDP, etc.|
The Action icon is a link which will lookup and display the rule that caused the log entry. More often than not, this says “Default Deny Rule”, but when troubleshooting rule issues it can help narrow down suspects.
On the Settings tab under Status > System Logs, this rule description can be configured to show in the log entries directly. The firewall can display the description in a separate column or a separate row. See Changing Log Settings for details.
Next to the source and destination IP addresses is . When this icon is clicked the firewall will perform a DNS lookup on the IP address. If the address has a valid hostname it will be displayed underneath the IP address in all instances of that address on the page.
Log entries for TCP packets have extra information appended to the protocol field displaying TCP flags present in the packet. These flags indicate various connection states or packet attributes. Common flags include:
|S – SYN:||Synchronize sequence numbers. Indicates a new connection attempt when only SYN is set.|
|A – ACK:||Indicates ACKnowledgment of data. These are replies to let the sender know data was received OK.|
|F – FIN:||Indicates there is no more data from the sender, closing a connection.|
|R – RST:||Connection reset. This flag is set when replying to a request to open a connection on a port which has no listening daemon. Can also be set by firewall software to turn away undesirable connections.|
There are several other flags and their meanings are outlined in many materials on the TCP protocol. The Wikipedia article on TCP has more information.
The log output shown in the GUI may be filtered to find specific entries, so long as they exist in the current log. Click to display the filtering options. See Filtering Log Entries for more information.
Adding Firewall Rules from the Log View (Easy Rule)¶
Easy Rule makes it simple to add firewall rules quickly from the firewall log view.
The icon next to the source IP address adds a block rule for that IP address on the interface. To be more precise, it creates or adds to an alias containing IP addresses added from Easy Rule and blocks them on the selected interface.
The icon next to the destination IP address works similar to the block action, but it adds a more precise pass rule. This pass rule allows traffic on the interface but it must match the same protocol, source IP address, destination IP address, and destination port.
Using Easy Rule to add firewall rules from the shell¶
The shell version of Easy Rule,
easyrule, can be used to add a firewall rule
from a shell prompt. When the
easyrule command is run without parameters,
the a usage message is printed to explain its syntax.
The way it adds a block rule using an alias, or a precise pass rule specifying the protocol, source, and destination, work similar to the GUI version. For example, to add a block rule, run:
# easyrule block wan 184.108.40.206
A pass rule must be more precise:
# easyrule pass wan tcp 220.127.116.11 192.168.0.4 80
Viewing from the Shell¶
When using the shell, either from SSH or from the console, there are numerous options available to view the filter logs.
When directly viewing the contents of the clog file, the log entries can be quite complex and verbose.
Viewing the current contents of the log file¶
The filter log is contained in a binary circular log so traditional tools like
grep, and so on cannot be used on the file directly. The log must
be read back with the
clog program, and may then be piped through another
To view the entire contents of the log file, run the following command:
# clog /var/log/filter.log
To restrict the log output to the last few lines, pipe it through tail:
# clog /var/log/filter.log | tail
Following the log output in real time¶
To “follow” the output of the log file, use the
-f parameter to
This is the equivalent of
tail -f for those used to working with normal log
files on UNIX systems:
# clog -f /var/log/filter.log
This will output the entire contents of the log file but does not quit afterward. It will instead wait for more entries and print them as they happen. This output may also be piped to other commands as needed.
Viewing parsed log output in the shell¶
There is a simple log parser written in PHP which can be used from the shell to produce reduced output instead of the full raw log. To view the parsed contents of the current log, run:
# clog /var/log/filter.log | filterparser.php
The log entries output one per line, with simplified output:
Aug 3 08:59:02 block igb1 UDP 198.51.100.1:67 198.51.100.2:68
Finding the rule which caused a log entry¶
When viewing one of the raw log formats, the ID number for an entry is
displayed. This rule number can be used to find the rule which caused the match.
In the following example, what rule with id
# pfctl -vvsr | grep 1000000103 @5(1000000103) block drop in log inet all label "Default deny rule IPv4"
As shown in the above output, this was the default deny rule for IPv4.
Why are there blocked log entries for legitimate connections?¶
Sometimes log entries are present that, while labeled with the “Default deny” rule, appear as though they belong to legitimate connections. The most common example is seeing a connection blocked involving a web server.
This is likely to happen when a TCP FIN packet, which would normally close the connection, arrives after the connection’s state has been removed or when an ACK is received outside the acceptable window time. This happens because on occasion a packet will be lost or delayed and the retransmits will be blocked because the firewall has already closed the connection.
These log entries are harmless and do not indicate an actual blocked connection. All stateful firewalls do this, though some don’t generate log messages for this blocked traffic even when all blocked traffic is logged.
This behavior will be present on occasion even if “allow all” style rules exist on all of the firewall interfaces because a rule set to “allow all” for TCP connections only allows TCP SYN packets to create a state. All other TCP traffic will either be part of an existing state in the state table, or will be packets with spoofed or otherwise invalid TCP flags.
A special variation of this that can indicate trouble is when asymmetric
routing exists on a network. In those cases log entries will be present showing
TCP:SA (SYN+ACK) packets being blocked rather than FIN or RST. See
Bypass Firewall Rules for Traffic on Same Interface and Static Route Filtering for
information on how to handle asymmetric routing.