Firewall table skips a PASS rule but hits similar REJECT below it
-
I bridged the LAN and WLAN interfaces on my pfSense SG-2440. I also changed the system tunables to enforce rules on the bridge and not on the physical interfaces. I have a table set up on the bridge (see attachment) that includes a set of 3 rules designed to allow all traffic between hosts on the bridge's subnet and out to the Internet, but disallow traffic with hosts on other subnets that the firewall manages. (The purpose of these rules is to create multiple isolated subnets on the firewall.) The attached screenshot shows these rules in positions 6, 7, 8 on the table.
At the top of the attached pic, you can see 3 log events that indicate the first PASS rule didn't work. Both hosts are on the interface's subnet (172.17.2.1/24), but these packets aren't passed; they're caught by the REJECT rule, instead. What's going wrong here?
UPDATE: Here's a screenshot of the "Local Subnets" port list. It's just the RFC1918 addresses.
-
The blocked packets are out of state. Such packets are blocked by the "default deny rule", which catches packets if no other rule matches.
So your undermost rule at this interface is needless.
But it's a strange behaviour that there is mentioned your manual added rule at the blocks. Maybe something messed up the rule set. I would try a reboot. -
The blocked packets are out of state. Such packets are blocked by the "default deny rule", which catches packets if no other rule matches.
So your undermost rule at this interface is needless.The last rule in the table provides a REJECT instead of a BLOCK action. I added it because it provides useful feedback to employees when they're configuring their workstations' and other systems' network services. The default BLOCK action provides no feedback, and that can be frustrating when trying to debug a failing service.
But it's a strange behaviour that there is mentioned your manual added rule at the blocks. Maybe something messed up the rule set. I would try a reboot.
Yes, it is strange. That rule should never be seen by the packet, since it's being sent between two hosts on the interface's subnet. I just rebooted, but it didn't change the behavior. These packets are still being caught by this rule. (See new screenshot.)
