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® software logs 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 fa-times in the firewall logs which match the traffic in question, pfSense software 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.

Protocol¶

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.

NAT Confusion¶

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

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.

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.

Review Rule Ordering¶

Firewall rules are generally processed as follows:

Floating Rules
Interface Group rules
Interface tab rules

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 fa-arrows-rotate 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.

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

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.

Asymmetric Routing¶

If reply traffic such as TCP:A, TCP:SA, or TCP:RA is shown as blocked in the logs, the problem could be asymmetric routing. See Troubleshooting Asymmetric Routing for more info.

Ruleset Failing to Load¶

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 fa-arrows-rotate 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.

Other Causes¶

There are other pitfalls in firewall rules, NAT, routing, and network design that can interfere with connectivity. See Troubleshooting Network Connectivity for more suggestions.