Firewall Rule Troubleshooting

From PFSenseDocs

Contents 1 Summary 1.1 Check the Logs! 1.2 Interface Selection 1.3 Protocol 1.4 NAT Confusion 1.5 Source and Destination Ports 1.6 Dangling States 1.7 Unfilterable Traffic

Summary

There are some times when you create a firewall rule and it just doesn't seem to work as expected. Did it block too many things? Did it allow too many things? Were there no changes at all? Hopefully this will help.

Check the Logs!

Review the filter logs, which can be found under Status > System Logs, on the firewall tab. You should be able to see if a packet is blocked, and if so, why. Click the red 'x' and the rule which caused the packet to be blocked will be displayed. If it says "Default Deny", and you were trying to allow a packet, then it did not match your rule.

Interface Selection

Be sure that your rules are on the proper interface. Imagine yourself sitting inside of your pfSense box. Sure, it's a little crowded in there, but this might help. Imagine packets flying at you from the different networks that your pfSense box ties together. You will place the rules on the interface they hit you from. If a packet is going from the LAN to the pfSense box, then out to the Internet, the rules still go on the LAN. If a packet is coming from the Internet, to the pfSense box, the rule goes on the WAN interface.

Protocol

You need to specify the protocol to which the rule will apply. Most often, this is TCP, UDP, or ICMP, but you may also regularly encounter other protocols such as ESP, AH, and GRE when dealing with VPNs. Some confusion arises when a person is really 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 systems involving NAT, you must 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 you typically only need to specify a source or a destination port, and rarely both (honestly the source port rarely matters at all). For example, if you want to allow ssh access to your pfSense box, only specify a destination port of 22. The source port of the client will be random.

Dangling States

If you made a new rule to block some 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 (Diagnostics > States) after altering the rules. If there is an existing state, it will always take precedence over any rules. You can clear all of the states, or look through the list and find states that apply to the host that will be originating the traffic.

Unfilterable Traffic

You may notice that some things you cannot filter. Not because pfSense isn't capable, but because they actually do not touch pfSense at all. A prime example of this is trying to keep one system on your LAN from accessing another system on the same LAN. This isn't possible if both clients are on the same subnet and switch; In that case, the routing of packets is handled at the switch level, and pfSense has no knowledge of the traffic. If you need to control access in this way, the systems in question should be on separate interfaces on your pfSense router. When on different "legs" of the network, their traffic will route through the pfSense system, and you will have full control of the flow.

On a related note, some older versions of pfSense are not able to filter traffic initiated by OpenVPN clients. In more recent versions (1.2.3 / 2.0 in the future), this traffic can be filtered.