Questions about 3 Interface Bridging with pfSense
-
chpalmer - when you say you use a third port as management - is that port part of the bridge?
My management is via a out-of-band management so I need all three interfaces into the bridge with a single IP only on the bridge.
Thanks,
No that third port is not part of the bridge. Its really the original LAN port. I bridge between WAN and OPT2.
WAN Rule-
You need a rule to access your GUI…Source- * Port- * Destination- BRG Address Port- 443 (or what ever you use...)
You also need a correct outbound rule on your bridge. For this rule- I have the actual bridge address for source. Not "BRG Address". I don't remeber why...
LAN (maintenance port) that I use... Is the default LAN that pfSense starts with... It simply uses the bridged interfaces as its WAN port.
You can use the config from my 2.1 test box for reference if you want... I use the same basic config on a production 2.0.1 box that I have... The posted config has allow all rules and the default pfsense password as that box never see's the light of day... :)
http://forum.pfsense.org/index.php/topic,46738.msg249820.html#msg249820
-
You should be able to do this.
If you are making a transparent firewall though you need to leave filtering on the bridge members, otherwise you cannot filter traffic entering the bridge which is kind of the point of a firewall! ;)I think the problem you are having here is doing stuff in the correct order. This sort of setup blurs the distinctions between WAN and LAN. From a routing point of view you have only one interface, OPT2 the bridge interface. I suspect that you are seeing a routing problem in which pfSense does not have a route back to the client to respond to https requests.
Hard to say.
Steve
I think you're onto something here… I think it's about having the right route in place. Question is how!?!
My firewall rule on the OPT2 interface is "any any any pass" so my thinking is that when I remove the WAN interface IP there is only the bridge IP and a firewall rule that allows all.
Stuck here... not sure what to try in terms of rebuilding it in a different order....
-
Sometimes with an 'unconventional' setup it's easier to do everything in one go by editing the config file manually. However it's also very easy to completely **** things up!
Perhaps the best way forward for you would be setup a two interface transparent firewall, using the third interface for management. Then when you have that working and can access the gui via the bridge you can add the third interface to the bridge.
Steve
-
Yea- by no means try to cut an paste from my or other config… If you use it just compare yours to mine. unless you know what your doing... Mines from a 2.1 build and may just be different enough to cause an issue or two...
But-
Here are some screenshots of what Ive done... This is the 2.1 box but the 2.0.1 box is identical.
The only thing Im still working on is what to have as the source on the Bridge Interface Rule. Using "Bridge Address" seemed to block me from accessing the GUI from WAN or OPT2...
On the Outbound NAT page... Manual to keep it from building rules for the OPT2 interface...
Im still experimenting...
-
Consider this…
If you setup a pfSense box with only one interface (which you can do since 2.x) it must be WAN. If you do that it will allow access to the gui on WAN for further configuration.
I would think that the final configuration you are looking for is the three interfaces (lan, opt1 and opt2) assigned as type 'none' and added to the bridge, brg0. And brg0 assigned as WAN.
filtering could be on both bridge members and the bridge interface. I needs to be on the members though if you want to actually do any firewalling.Steve
-
Thanks for the comments guys…
cfpalmer - Don't think I'm far away and I'm not sure I need the NAT mapping as I'm using a /29 subnet of public IP addresses so there shouldn't be any NAT involved. In fact it's a requirement that there isn't.
stephenw10 - You've got it exactly - the difference being I've got the bridge as OPT2 rather than WAN... I'll give that a go and report back. Also see what you mean about needing to filter on members too but will come back to that once bridge is working 100%.
Will report back once I've done some testing...
-
The NAT is for the router only in case you lock yourself out… Your ISP will never know... ;) Your right though. You probably dont need it if your just accessing the GUI. But I like to make the internet available to it in case I need the forums here, Google or one of the firmware mirrors... In any case, give it a private address and make rules that allow what you need... GUI or full access to the web.
Good Luck!
-
Hi Guys,
Looking good - I have now made the WAN interface as the bridge0 and the physical emX ports as LAN, OPT1 and OPT2. I've removed all IPs except for WAN and looking good. I think the critical piece of info was that for pfSense to support a single interface it has to be on WAN interface.
I can reach both devices that are plugged into the physical ports ! Happy Days!
Stephenw10 - so now to the member filtering section you mentioned earlier…. .
I'm not 100% sure I grasp the concept of filtering when the bridge is involved. I want to be able to achieve all access out from ports in the bridge and control what is allowed in from the "Internet".
Currently member filtering is set to 0 - Does that mean the rules on tabs LAN, OPT1 and OPT2 don't get applied?
I currently have a rule on my WAN (bridge0) interface that allows all traffic.
-
Currently member filtering is set to 0 - Does that mean the rules on tabs LAN, OPT1 and OPT2 don't get applied?
I must confess I'm a little vague here but my understanding is that's exactly what it means.
In fact filtering cannot be disabled in pfSense 2.0 (unlike 1.2.3 where you could choose filtering or non-filtering bridge) setting net.link.bridge.pfil_member to 0 simply removes the rules from the the filter.You should definitely have net.link.bridge.pfil_member set to 1 in order that you can apply firewall rules to traffic entering the bridge from the external network.
You could also have net.link.bridge.pfil_bridge set to 1 to filter traffic entering pfSense from the bridge (things start to get weird conceptually ;)) which you could use to limit who has access to the gui. I'm a bit unsure on this though.Clearly you are going to have to do some testing to make sure rules are being applies where you think are.
Steve
-
Hmmm my test is showing I've got a very open Firewall! :$
I'm moving around a rule to block ICMP traffic and it's not getting blocked anywhere I put it and with the system tunables back as default it's still not playing ball!!
Argh!!!
-
You will have to clear the state table between tests to be sure your new rules are being applied.
Steve
-
Bingo! That's what I needed to do!
Testing is going much better now! :)
