Netgate is offering COVID-19 aid for pfSense software users, learn more.
Firewall Rule Troubleshooting¶
There are times when a firewall rule does not seem to work as expected. Did it block too many things? Did it allow too many things? Were there no changes at all? Use this document to figure out what went wrong.
Check the Logs!¶
Review the filter logs, found under Status > System Logs, on the Firewall tab. The log will show if a packet is blocked, and if so, why. Click the action icon ( or ) at the far left and the GUI will show the rule which caused the packet to be blocked. If it says “Default Deny”, and the packet should have been allowed, then it did not match any rule in the ruleset.
Be sure that the rules are on the proper interface. Imagine sitting inside of the firewall. Sure, it’s a little crowded in there, but this can help. Imagine packets flying in from the different networks that the firewall ties together. The rules will be placed on the interface they entered from. If a packet is going from the LAN to the firewall, then out to the Internet, the rules checked by the firewall are on the LAN interface tab. If a packet is coming from the Internet to the firewall, the corresponding rule goes on the WAN interface tab.
Firewall rules are generally processed as follows:
Interface Group rules
Interface tab rules
See Firewall Rule Processing Order for more details.
If a floating rule with quick checked passed the traffic, then a block rule on an interface would have no chance to match the traffic.
The protocol to which the rule will apply must be specified. Most often, this is TCP, UDP, or ICMP, but other protocols such as ESP, AH, and GRE are regularly encountered when dealing with VPNs.
Confusion arises when a firewall administrator is unsure of what protocol to use. A rule set with TCP may not work because the application being filtered may actually use UDP instead. When in doubt, try using TCP/UDP.
When crafting rules for firewalls involving inbound NAT connections, remember to use the private IP address as the Destination. This applies for port forwards as well as 1:1 NAT
Source and Destination Ports¶
When crafting rules, bear in mind that typically only a source or a
destination port needs to be specified, and rarely both. In the majority of
cases, the source port does not matter at all. For example, to allow ssh access
to the firewall, only specify a destination port of
22. The source port
of the client will be random.
If a new rule was made to block traffic, but packets still get through, there may be an existing state that is allowing the traffic to pass.
To eliminate this as the cause, clear the states after altering the rules (Diagnostics > States, Reset States tab). If an existing state is present, it will always take precedence over any rules. All of the states may be cleared, or look/filter through the list and find states that apply to the host that will be originating the traffic.
Certain traffic cannot be filtered. Not because the pfSense® software isn’t capable, but because they actually do not touch the firewall at all. A prime example of this is trying to keep one device on the LAN from accessing another device on the same LAN. This is not possible if both clients are on the same subnet and switch; In that case, the routing of packets is handled at the switch level (layer 2), and the firewall has no knowledge of the traffic. If there is a need to control access in this way, the devices in question must be on separate firewall interfaces. When on different “legs” of the network, their traffic will route through the firewall, the firewall will have full control of the flow.
Port Forward pass action¶
When creating a port forward, the pass action will bypass firewall rules and pass the traffic directly through without filtering. Change the setting to create an associated rule and then arrange the block rule above the resulting pass rule.
UPnP / NAT-PMP passed traffic¶
If UPnP/NAT-PMP is enabled and a LAN device opens a port to the world, the traffic may still get in even if it appears it should otherwise be blocked.
If reply traffic such as
TCP:RA is shown as
blocked in the logs, the problem could be asymmetric routing. See
Troubleshooting Blocked Log Entries due to Asymmetric Routing
for more info.
It is also possible that the rules are not being loaded properly. Typically this would result in a notification in the GUI, however manual tests can be performed to check.
From the GUI, visit Status > Filter Reload. Click Reload
Filter wait for the process to stop, then scroll to the bottom of the page to
see if the last line says
Done. or if it stops. If it stops, for example in
a particular package, then there may be a problem with that package.
The ruleset can also be verified from the console or Diagnostics > Command in the Shell Execute box by running:
pfctl -f /tmp/rules.debug
If an error is displayed, it may have an obvious fix, or search for that error to find possible resolutions.