Building a WAN Bridge
-
See https://forum.pfsense.org/index.php?topic=84447.msg464023#msg464023 for reasons behind this post.
With the Thanksgiving Holiday here today I decided to undertake trying to rebuild my WAN bridge setup on primary pfSense box and configure it a little differently.
The last time I tried the modem would not give the Bridge an address via DHCP. I believe I was missing a step so Im giving it another go.Background-
I have a business connection from my ISP WaveBroadband. I have 1 static IP that I use at this location and host a few server processes on an Windows 2008 Server box which has the static IP assigned on one of its interfaces.
I can also use two DHCP addresses from the ISP for a total of three addresses. My wish is to only use a firewall between the server and the modem with no nat. This should help me when I finally get a static IPv6 address from them for the server. I have a fairly large network behind the WAN including several SIP devices that I have behind Siproxd.
To be continued-
-
From my notes-
Open GUI
Go to Assign
Make new Interface Assign to MSK3 ( I actually already had this done as this is part of the old bridge which was between the WAN interface and Server)
Make new Interface Active and call it "Server" ( I actually already had this done as this is part of the old bridge)
Make Bridge. Add "Server" Interface and (existing) "Test" Interface
(I had to have an another available interface as my second due to (The following input errors were detected:You must select at least 2 member interfaces for a bridge.))Assign WAN to Bridge
Set new MAC for WAN that does not = any interface in my system.
Make new interface and assign it to SK0 (old WAN)
Make new interface active and call it "Modem"
Edit Bridge to make it "Server" and "Modem"
Set /Advanced Settings/System Tunables/net.link.bridge.pfil_bridge (Set to 1 to enable filtering on the bridge interface) to 1.
reboot everything
This time the system grabs an address for the new WAN making it obvious I missed something last time. I did reboot the pfSense box this time and that is the only difference I remember.
Checking MXToolbox I find my email server is no longer reachable (as I suspected)
I now need to look at all my incoming firewall rules intended for the server and set their interface to "Modem". Once this is done MXTool box is able to connect and report.
Continued-
-
So- What is the difference?
Setting up the server on NAT:
This by far is easiest. Using a VIP for the static address and using 1:1 NAT can be done on another LAN subnet for security and ease. All incoming rules for this network end up on the WAN rules page.But some setups dont work well when the server is behind a NAT. So-
Setting the Public Static on the server and bridging its interface with the WAN port:
Since my WAN address and Static address are on two different subnets (and some other reasons on my ISP's side) I can not see my server on its public IP address from inside my local LAN. I have to use a second interface on the server with a local LAN address and set rules in the DNS forwarder for my email clients to find it. All incoming rules are on the WAN page. I have to isolate the servers LAN interface so it cannot access the public internet.Setting the Public Static on the server and bridging its interface with the Modem port, set WAN as the bridge:
Same as above but- Now my incoming rules are split up. I have OpenVPN servers on my WAN. So incoming rules for the WAN remain on the WAN tab but Incoming rules for the server are on the Modem tab.
Hopefully this is good information for anyone searching… :)
-
One things occurs to me here.
Did you change the sysctls that control bridge filtering? If not then the pf filtering is disabled on the bridge interface by default. That would imply any rules on your WAN interface are disabled, including the default drop rule. Of course in order to get to the WAN interface all incoming traffic has to go via the modem or server interfaces so default rules apply there. Is that what you found?Steve
-
One things occurs to me here.
Did you change the sysctls that control bridge filtering? If not then the pf filtering is disabled on the bridge interface by default. That would imply any rules on your WAN interface are disabled, including the default drop rule. Of course in order to get to the WAN interface all incoming traffic has to go via the modem or server interfaces so default rules apply there. Is that what you found?Steve
net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface is set to 1. This must be a hold over from another time I was messing. I thought it was set default so I didn't mention it. Im adding it to the logs above..
Thanks Steve!