pfSense

I currently don't have access to the test box, but I will later on this evening, and once I do, I will post the output of:

ifconfig -a

and

cat /tmp/rules.debug

Cheers

I see what you mean about the Anti-Lock out rule, however when I first discovered this issue, I was actually using a 3rd OPT1 interface (with WAN and OPT1 bridged, with LAN on a private subnet), and the same problem was happening - i.e. block everything on OPT1 tab, yet WAN rules are evaluated when arp cache is flushed and states reset.

Any ideas/comments?

I really do feel that this is a serious issue

Forgot to mention, indeed the host LAN side host (or OPT1 side host depending which scenario I'm doing), always appears as being on WAN in the arp cache for me...

Also forgot to mention, that if using the 3 interface setup (with WAN and OPT1 bridged, with LAN on a private subnet), if a host on the OPT1 interface (which should not be allowed to access anything) uses the WAN IP address of pfsense as its default gateway, then it can access hosts on the LAN interface, provided the WAN rules allow for this. I have tested this and it does indeed do this.

IMHO, the WAN rules should never be evaluated for hosts on the OPT1 interface.

This is the major issue

Does anyone have an update on this? This is a major security issue in pf.

Please keep in mind that I discovered this issue on a prodduction system, as restricted hosts were able to access my internal LAN hosts (not just the router web GUI)

Can you please try this command and see if it changes anything:
sysctl net.link.bridge.pfil_local_phys=1

This scenario is described in the if_bridge man page:

The packets destined to the bridging host will be seen by the filter on
     the interface with the MAC address equal to the packet's destination MAC.

http://www.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

So it is the expected behavior, such configurations should not be used if that isn't the behavior you desire. If you set the default gateway on hosts to an IP on a different interface of a bridge, all that host's traffic will be destined to the WAN MAC and hence have the WAN rules apply.

net.link.bridge.pfil_local_phys does not change the behavior, it does as described whether that's 0 or 1.

Hi Chris,

I appreciate what you are saying, but the point of concern here is that the host shouldn't be able to set the WAN interface as the default gateway, as the only rule on set on the respective tab is block all (i.e. no traffic should be allowed through). In my test, I was using OPT1 as the "restricted" interface (which had the block all rule).

And please remember that the problem goes away after you wait for a few minutes. This only happens when the arp table is flushed and the states are reset (for example at system boot)

Patch integrated in the builds. Please test the latest one.

I'll test this latest snapshot ASAP.

Very keen to see the results

A note on the last comment there:
From that config it looks like "Phones" is bridged to WAN, not LAN, which is more consistent with your comment about the Phone device having a public IP and that it uses the ISP gateway. (It seems that saying it was bridged to LAN was a typo of sorts)

Yes, my bad. PHONE is bridged to WAN not LAN

The original issue is sorted, however the problem from #22 could still be an issue.

This possibly is to late for 2.0 since there are if_bridge(4) chagnes involved which might become problematic.
The problem is identified and analyzed and half solution was tested so i think 2.1+ is a better candidate.

it works exactly as it should per the man page, there are just certain ways you shouldn't configure it or you should expect the results. A documentation issue at this point, if it can be fixed in the future without a lot of effort we can revisit.

Chris, was that in response to the issue I noted or the original one? I could understand the IP of the management interface leaking into the bridge, but the gateway leaking into it seems strange.

Continuing discussion of https://redmine.pfsense.org/issues/2744

Odd that it's just appeared now on an established and tested setup after an upgrade to latest snapshot.

What's the recommended workaround? Presently I've just added a static ARP entry on the device connected to the "Firewall" interface.

This should work better on pfSense 2.2 as of 1 week ago!