Default pass rules and bridge member filtering

yousif · Apr 14, 2016, 6:15 PM

So I have a bit of a toughie here. pfSense 2.2.6, with that new option to log default pass rules in the f/w log. (Love that option btw, would never have gotten this far debugging without it).

I have a LAN bridged to an OpenVPN tap adapter via a bridge interface created in pfSense. Pretty standard, that's how you do a bridged setup with OpenVPN. Both interfaces (let's call them LAN and TAP) are members and things work the way you would expect.

Except broadcast traffic filtering via the firewall on a per-member basis via firewall rules!

Stop me if you've heard this one before - I have two networks bridged together, each with a DHCP server, and I want each network segment to deal with DHCP on its own. So I filtered DHCP off of the interfaces by adding a rule that blocks all traffic to destination ports 67 and 68. I know this rule works on non-bridged interfaces because I have tried it with success. So the concept is ok. In pf syntax, this rule looks like:

block drop in quick on igb1 inet proto udp from any to any port 66 >< 69 label "USER_RULE: Deny DHCP on the LAN"

(igb1 is LAN). I added a similar rule to TAP.

However, the DHCP traffic is not being filtered. I can see the incoming requests on all member interfaces as expected:

13:58:32.535341 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 300]

The problem is the DHCP server on the segment across the bridge is seeing the request, and tries to respond. I cannot filter the request nor response.

Debugging the firewall, the logs tell me the reason the packets are being permitted is because of the default pass rule:

pass out log inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"

This rule is NOT a quick rule according to pfctl, so it should not execute before my rules. In pfctl, the default rule is listed first, my rules are below, but my rules are QUICK rules, so shouldn't my rules get executed first? I can't for the life of me figure out why my rules won't fire. They are very general, blocking ports 67-68, but do not look at source or destination IPs, so they should work!

What am I missing?

Thanks in advance for any assistance.

gcu_greyarea · Apr 16, 2016, 1:22 AM

I could be completely wrong, but I'll give it a shot anyway…
Somebody mentioned in a bridge related post to not use the LAN interface when building a bridge.
The reason are the default rules on Lan, so it's better to bridge with Opt interfaces (if available)

Also have you tried to put you DHCP block rule into Floating Rules?

I filter on the bridge itself and i had to explicitly setup a pass rule for dhcp...

You could enable filtering on the bridge in advanced setting (pfil-bridge=1)

yousif · Apr 18, 2016, 2:26 PM

Hey, thanks for the reply. I have not tried a floating rule. May as well, that's a good idea.

In terms of filtering on the bridge, I did try that and it actually worked a long time ago. It's not a long term solution for me though, because my use case is a little more complicated. What I actually want to do is have three interfaces on the bridge (TAP1, LAN, TUN2), one of which blocks DHCP to LAN and one which does actually permit it.

If I can't get this to go, I may switch to a routed tunnel for one of the interfaces there, and just flatly permit DHCP, but I like the benefits of broadcast traffic on both segments.

What I was trying to ask about is if the scenario I want will work given that pfSense can filter on individual bridge member interfaces. Except I can't get it to work, no rule I write will catch that traffic.

yousif · Apr 18, 2016, 4:11 PM

Ok just a follow up here, to note interesting behavior.

I am still filtering on member interfaces; when I added a floating rule that blocked DHCP (destination ports 67-68) on all three aforementioned interfaces, this had the effect of blocking traffic. If any one of those interfaces is not included in that floating rule, all DHCP traffic flows to all 3 interfaces. Interesting.

I am going to try to use differing combinations of quick and not quick rules and try the previous poster's suggestion of block all and then explicitly pass and report back.

If this doesn't work, I suppose I may also try to remove the LAN from the bridge and use an OPT interface per the previous suggestion, although I can't tell why this would make a difference. Aren't all interfaces treated the same firewall-wise, except for some anti-lockout rules for LAN that are hardwired?

gcu_greyarea · Apr 19, 2016, 9:22 AM

Hi yousif,

Sounds like you had some luck with floating rules …

https://doc.pfsense.org/index.php/What_are_Floating_Rules

I'm referencing the the Floating rules help page here ( for my own reference )

https://doc.pfsense.org/index.php/What_are_Floating_Rules

You mentioned using Quick Rules ...

Floating Rules are parsed before rules on other interfaces. Thus, if a packet matches a floating rule and the Quick option is active on that rule, pfSense will not attempt to filter that packet against any rule on any other group or interface tab.

Just testing my logic:
The sentence above implies that -

a DHCP request arrives at the LAN interface
the Floating rule fires first - it is a quick rule - drop destination 67-69
-( its a bridge - does that mean the dhcp req arrives at all 3 IF at the same time ? - i think Yes)
so if YES - the Floating rule blocks the traffic only on interfaces selected
if one bridge member is not part of floating rule - the the dhcp req will hit that interface - and in turn all other interfaces
floating & quick rule implies - all other rules on all other interfaces will be ignored
interface rules wouldn't work anyway because they are inbound

According to above (possibky flawed logic).

floating rule against all bridge members -> blocks dhcp traffic
floating rule against some (but not all) member interfaces -> does bot block

Your bridge is configured to filter on member interface (pfil ridge_member=1)

So effectively as the the DHCP request arrives on one interface - it hits all members of the bridge.

In this Case I would:

create any-any deny dest ports 67-69 rule on each member Interface of the Bridge (Lan, Tap, tun)
Interface rules are inbound by default
create 3 Floating Outbound rules (not quick) for each member interface deniyn dest ports 67-69
"Not quick" ensures your Interface rules wont get overridden

gcu_greyarea · Apr 19, 2016, 11:56 AM

I did some googling and and kept finding information about DHCP using raw sockets.
Apparently iptables (and maybe pf ) based firewalls won't be able to filter that traffic as the OS processes raw sockets before the firewall rules apply.

Again, I know too little about this subject, but seek some clarity for yousif's questions as I run a similar setup.

Would be great if somebody with in-depth pfsense could shed some light on this?

yousif · Apr 21, 2016, 6:05 PM

Thanks again for your input. I had tried all of the combinations you mentioned with no luck. I don't know if the issue is raw sockets, or if it's because bridging essentially makes the interface members the same interface, so everything always appears to the f/w to hit at the same time.

To lend a little credit to your raw socket idea, I did notice that most other rules (not broadcast/DHCP type filtering rules) can be filtered on individual interface members. For instance, a general rule to block all traffic entirely DOES work on a specific interface of the bridge even if the other two aren't blocking all traffic. Even with this rule in effect, though, the DHCP traffic makes it in, if not all 3 interfaces are blocking ports 67 and 68.

So, it's interesting how it even manages to block DHCP at all, even if all 3 interfaces carry the same block rule.

For the record, I use ports 67-68 only as destination ports to block, as tcpdump does not reveal any traffic on 69.