WebGUI inaccessible on Bridge
I have pfSense set up with 3 interfaces:
WAN & LAN are Bridged and the bridge is assigned to opt1.
WAN and LAN interfaces are set to none and opt1 is set to a Static IP address which I am using to access the WebGUI. The default anti-lockout rules on the LAN interface are therefore not applicable.
I have disabled filtering on all bridge member interfaces (net.link.bridge.pfil_member is set to 0).
The WebGUI is set to https: on port 8181.
All filtering is working perfectly except that I am getting locked out of the WebGUI when rules are applied. The firewall logs shows blocked packets with TCP:FA, TCP:PA and TCP:SA flags, all on the bridge interface.
I´ve tried setting up rules to allow all TCP traffic from the management IP to any destination (and vice-versa) with any flag set and I am still getting locked out. Any suggestions?
Can you post the rules you are using?
Thanks a lot for your reply.
Here are the rules I have set as well as a sample of the firewall logs.
You are looking at floating rules. These rules work off last matching unless set specifically on the rule to match immediately. What rules do you have set on the bridge interface and on WAN and LAN? I would suggest putting in allow all in LAN and WAN, and then filtering with rules on the bridge and not in floating.
Both rules are set to apply immediately if matched. I don´t have many rules but they are all applied as floating rules and all are working very well except for these two.
I don´t have any rules on the WAN interface or the Bridge interface. The only rule on the LAN interface is the default anti-lockout rule.
I have disabled filtering on the member interfaces so I wouldn´t have thought I would need any rules on the WAN / LAN interfaces. But I see some blocks originating from the LAN interface…... Unless I am overlooking something.
Give this link a try, this is a write up I have submitted to pfSense. We manage our interface from the WAN instead of any of the other interfaces, seems to work.
Hi Vard0. If you look just a few threads down below yours, you'll find my report of exactly the same problem, with a few more details.
My initial configuration was essentially identical to yours - opt1 bridging the LAN and WAN interfaces, each of which was a physical network interface. I spent days on this and I tried a lot of configurations and most of them would seem to work for a bit, then suddenly the WebGUI would go away following a rule change. I can't absolutely swear to it that I tried putting the management address on the WAN interface, though I think I did, but from what I saw of the problem mechanism I'd expect that to have the same issues.
Based on tcpdump sniffing, the issue seems to be that at some point, often following a rule update, the web GUI starts answering TCP connections from the wrong interface of the bridge, and its reply packets do not get bridged over to the interface the query is coming in from, so a connection to the SSH or HTTP port never completes. ???
In the end, this past Saturday I started over from scratch, enabled VLANs in the initial setup prompt, created a separate VLAN sub-interface on one of the network cards, and declared that to be "LAN" and to have the management address. I then declared the network card to be an optional interface (renamed INTERNAL) and bridged that with the WAN interface. That's working fine now.
If putting the management IP on the WAN works for you, great! Just mentioning this as another option.