Firewall in transparent bridge mode "turns arround" - very strange issue
-
Hi everybody,
got a very strange issue with firewall in transparent bridge mode. Here is my setup:
There are four NICs in the pfsense box. All are Intel-based.
pfSense-Version: 1.2-BETA-1-TESTING-SNAPSHOT-05-29-2007 built on Sun Jun 3 12:44:39 EDT 2007
Network available: x.y.z.128/25
Gateway: x.y.z.129
WAN: Static, x.y.z.130/25, Gateway: x.y.z.129
LAN: Static, Bridged with WAN, x.y.z.135/25
DMZ (Opt1): Static, 192.168.6.1/24
POOL (Opt2): Static, 192.168.7.1/24I'll skip all details about DMZ and POOL, since it probably has no influence at all with respect to my problem.
Under Advanced, "Filtering Bridge" is enabled.
For LAN the dhcp server is enabled:
Subnet: x.y.z.128
Subnet mask: 255.255.255.128
Available range: x.y.z.128 - x.y.z.255
.. hence it serves ips from that range.Clients get IP adresses with the following details:
Verbindungsspezifisches DNS-Suffix: mydomain.local
Beschreibung. . . . . . . . . . . : Intel(R) PRO/1000 PL Network Connection
Physikalische Adresse . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse. . . . . . . . . . . . : x.y.z.181
Subnetzmaske. . . . . . . . . . . : 255.255.255.128
Standardgateway . . . . . . . . . : x.y.z.135
DHCP-Server . . . . . . . . . . . : x.y.z.135
DNS-Server. . . . . . . . . . . . : x.y.z.135
Lease erhalten. . . . . . . . . . : Donnerstag, 5. Juli 2007 15:21:28
Lease läuft ab. . . . . . . . . . : Donnerstag, 5. Juli 2007 17:21:28Everything usually runs fine this way. But I just realized the following strange issue.
Usually with this setup I can ping from inside the following ips:
Internal bridged interface: x.y.z.135
External bridged interface: x.y.z.130
any external pingable adress, hence everything works fine.From external I cannot ping x.y.z.130 - thats fine
I cannot ping x.y.z.135 - that's also fine.
Management interface is reachable from from inside by pointing to internal interface and is not reachable on any interface from the outside. - that's how it should be.But now it comes: After a reboot (at least I think it happes only at reboot) the following situation MIGHT (non-deterministicall) be:
Internal: the same, no change.
However, from external:
I can ping x.y.z.135 - that should not be!!
I cannot ping x.y.z.130 - that is ok … (but would not make me wondering if ping would work)
Management interface still reachable from the inside on both interfaces (130 and 135).
Management interface now also reachable from OUTSIDE with x.y.z.135- that's a security issue!!! Bummer!Hence, it seems that somehow the bridge "turned arround". This also influences other services like the PPTP-VPN which is bound to x.y.z.130. In the "turned arround" mode, this cannot work anymore, since the 130 is now "after" the filtering bridge.
From clients point of view - i.e. internal - everythings seems normal, that is traffic gets routed. Hence, there is no visible change on the inside.
Clearly, the first thing to look at are the interfaces - but there is still everything ok- WAN is bound to x.y.z.130, LAN is bound to x.y.z.135 (bridged) - so this seems ok, however, it behaves not according to this..
So the big question is: Am I doing something wrong, or is this a bug?? How can I force the bridge to always stay in the mode as intended?
Some of the post posted in the last time with respect to tranparent bridging (antispoofing, etc.) seem related, however, nowhere there was mentioned this "turn-arround" - however, also there it might be interesting to check if suddenly the internal ip is reachable from outside - maybe this is the origin of all the problems…
UPDATE: I manged to get back to the "good" behavior after two reboots without changing anything. So there is something non-deterministic with boot up!
Since the two interface are two onbaor intel chips I was suspecting for a short time, that maybe freebsd assings them non-deterministically. However, this theory is disproved with the fact that in both modes the MAC adresses are with the same interfaces:
Good mode: xx-xx-xx-xx-xx-b2 -> em2 (WAN) and xx-xx-xx-xx-xx-b3 -> em3 (LAN)
and also in "bad mode": xx-xx-xx-xx-xx-b2 -> em2 (WAN) and xx-xx-xx-xx-xx-b3 -> em3 (LAN)UPDATE2: I was too quick with beeing happy… maybe the firewall was not booted completely yet. After a short time of beeing happy, that the management interface was not accessable and also no ping worked from outside... suddenly the "bad mode" was back. Hence there are two possibilities: 1.) The firewall was not bacck yet and I just was too qucik, or worse, the effect can simply happen without boot - that would be really nasty...
Hence, the theory, that the drivers get mismatched does not hold. Other suggestions?
Best regards
Arno -
Hmm..
I'm getting more and more confused with this setup…
I was no able to get back to the "good" situation as described in my last post. I rebooted many times, but always the access from external to x.y.z.135 (LAN IP brideged with WAN) remains. Hence also web interface is accessable from outside. So I'm starting to wonder - did that once really work as described in my last post. I could swear that when seeting it up, I tested all these things, and I was happy with what I got, hece it should have been different.
After looking at the /tmp/rules.debug I see a line
# make sure the user cannot lock himself out of the webGUI or SSH anchor "anti-lockout" pass in quick from any to x.y.z.135 keep state label "anti-lockout web rule"
where I'm wondering… pass in from ANY - so this clearly states that to my bridged interface everything is allowed - shouldn't that be constrained to LAN? OR am i mistaken here?? Also for a "web-antilockout - why do we pass everything? And don't constrain it to http or https?
I'm right now not sure - maybe I'm hunting ghosts right now, and everything is as it is supposed to be since, everything works from inside, and from outside I cannot ping any server inside (besides the bridged LAN-IP). Sooo.. is this correct?
Best regards
Arno -
After a lot more testing I come to the conclusion that simply my old observations must have been wrong (maybe I shoudn't do setups at late night) ;) .
Summarizing this meas: the confusion started with the fact that the bridged LAN IP can be accessed from the outside network (ping and webinterface and ssh). All other observation where just due to other effects, e.g. the pptp stuff still works.
Hence, what remains from here is just, that it's probably a bug that the internal ip can be accessed from outside in bridge mode. Furthermore, this cannot be deactivated by deactivating the anti-lockout rule. This is discussed here: http://forum.pfsense.org/index.php/topic,5441.msg32479.html#msg32479 .
Sorry for the long post and the confusion.