Netgate is offering COVID-19 aid for pfSense software users, learn more.
Troubleshooting Firewall Rules¶
This section provides guidance for troubleshooting issues with firewall rules.
Check The Firewall Logs¶
The first step when troubleshooting suspected blocked traffic is to check the firewall logs (Status > System Logs, on the Firewall tab).
By default pfSense® will log all dropped traffic and will not log any passed traffic. Unless block or reject rules exist in the ruleset which do not use logging, all blocked traffic will be logged. If there are no log entries with a red in the firewall logs which match the traffic in question, pfSense is not likely to be dropping the traffic.
Check the State Table¶
Attempt a connection and immediately check the state table at Diagnostics > States and filter on the source or destination to see if a state exists. If a state table entry is present, the firewall has passed the traffic.
If the rule in question is a pass rule, the state table entry means that the firewall passed the traffic through and the problem may be elsewhere and not on the firewall.
If the rule is a block rule and there is a state table entry, the open connection will not be cut off. To see an immediate effect from a new block rule, the states must be reset. See Firewall States for more information.
Review Rule Parameters¶
Edit the rule in question and review the parameters for each field. For TCP and UDP traffic, remember the source port is almost never the same as the destination port, and should usually be set to any.
If the default deny rule is to blame, craft a new pass rule that will match the traffic to be allowed. If the traffic is still blocked, there may be some other special aspect of the packets which require additional handling in the rule configuration. For example, certain multicast traffic may need to have Allow IP Options enabled, or the log entries may be due to asymmetric routing, or the packets may have an invalid combination of parameters such as a fragmented packet with “Don’t Fragment” set inside.
See Bypass Firewall Rules for Traffic on Same Interface and Static Route Filtering for information on how to handle asymmetric routing.
In such advanced cases, running a packet capture for the traffic in question can help diagnose the problem. Refer to Packet Capturing for more information on how to capture and analyze packets.
Review Rule Ordering¶
Remember that for interface tab rules, the first matching rule wins – no further rules are evaluated.
Rules and Interfaces¶
Ensure rules are on the correct interface to function as intended. Traffic is filtered only by the ruleset configured on the interface where the traffic is initiated. Traffic coming from a system on the LAN destined for a system on any other interface is filtered by only the LAN rules. The same is true for all other interfaces.
Enable Rule Logging¶
Determine which rule is matching the traffic in question. The hit counters in the rule list can help with this to some degree. By enabling logging on pass rules, the firewall logs will show an individual entry specifically to determine which rule passed the connection.
Troubleshooting with packet captures¶
Packet captures can be invaluable for troubleshooting and debugging traffic issues. With a packet capture, it is easy to tell if the traffic is reaching the outside interface or leaving an inside interface, among many other uses. See Packet Capturing for more details on troubleshooting with packet captures.
New Rules Are Not Applied¶
If a new rule does not appear to apply, there are a couple possible explanations.
First, If the rule is a block rule and there is a state table entry, the open connection will not be cut off. See Check the State Table.
Second, the ruleset may not be reloading properly. Check Status > Filter Reload to see if an error is displayed. Click the Reload Filter button on that page to force a new filter reload. If an error is displayed, resolve the problem as needed. If the cause is not obvious, consult support resources for assistance.
If none of the above causes are to blame, it’s possible that the rule is not matching at all, so review the traffic and the rule again.
There are other pitfalls in firewall rules, NAT, routing, and network design that can interfere with connectivity. See the doc wiki article on Connectivity Troubleshooting for more suggestions.
For additional information, you may access the Hangouts Archive to view the June 2016 hangout on Connectivity Troubleshooting which contains much more detailed troubleshooting procedures.