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.

Tip

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.
../_images/firewall-log_webgui.png

Example Log Entries Viewed From The WebGUI

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.

Tip

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 fa-info. 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.

See also

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 fa-filter 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 fa-minus-square-o 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 fa-plus-square-o 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 1.2.3.4

A pass rule must be more precise:

# easyrule pass wan tcp 1.2.3.4 192.168.0.4 80

Viewing from the Console Menu

The raw logs may be viewed and followed in real time from the filter.log file using option 10 from the console menu. An easy example is a log entry like that seen above in Figure Example Log Entries Viewed From The WebGUI:

Aug  3 08:59:02 master filterlog: 5,16777216,,1000000103,igb1,match,block,in,4,0x10,,128,0,0,none,17,udp,328,198.51.100.1,198.51.100.2,67,68,308

This shows that rule id 1000000103 was matched, which resulted in a block action on the igb1 interface. The source and destination IP addresses are shown near the end of the log entry, followed by the source and destination port. Packets from other protocols may show significantly more data.

See also

The format of the filter log file is described in detail on the pfSense documentation wiki.

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 cat, 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 program.

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 clog. 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 1000000103:

# 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.