Bridging WAN + OPT1 for second WAN IP through ISP’s DHCP.
-
I have the following interfaces:
- WAN
- LAN
- OPT1
- BRIDGE0 (WAN + OPT1, unassigned)
The intent is to pull a second WAN IP from ISP’s DCHP server. I added the allow DHCP rules (i.e to and from 67/68) on OPT1 directly and a computer connected to OPT1 successfully pulls a wan IP.
However, the traffic is blocked unless I allow all from any to any on OPT1. I know this isnt ideal, but is there a risk traffic from other interfaces like LAN or VPN server can exit through OPT1?
OPT1 pulls a separate wan ip and gateway. Pfsense doesnt add this gateway or NAT it. Traffic in theory passes freely and the device isnt “aware” of pfsense. This is why i think allow any to any should be fine on opt1. Even if something on LAN tries to enter OPT1, there shouldnt be any routing or NAT that would allow it to exit (pfsense doesnt even have the gateway or ip address). Is my understanding correct?
The OPT1 interface doesnt have any ip or other configuration so selecting OPT1 subnet or address in the source doesnt work. The wan ip and subnet can and does change so i dont want to manually hardcode the source.
Is there an elegant way around this? One simple solution would be to filter based on mac address, but my understanding is that pfsense nor opnsense can do this.
The best solution i have in mind is to add explicit block rules from LAN and VPN subnets on OPT1 and allow all, any to any below this. Does anyone have an easier workaround? And if not, should I be adding a block rule for firewall/loopback addresses as well?
• use-case: isolating tor traffic to separate ip
• isp does not provide static ip to residential customers.
• not wanting to use unmanaged switch. Will require a 10G switch in my case. Good ones are expensive and just keeps things cleaner. Also provides a solid transparent firewall for blocking incoming connection on OPT1.Thanks a lot!
-
@mj9768
If you allow any on OPT1 also access to your local network is allowed from this interface of course. But there is nothing allowed from WAN, even OPT1 is bridged with it.All you need to allow might be access to public destinations, however. So just add a proper rule to the interface.
To achieve this, I create an RFC 1918 alias and use it as destination in a pass rule with "invert match" checked:This here is a floating rule, but in your case you should put it on OPT1 and you might want to allow any protocols.
This presumes, that the tunables net.link.bridge.pfil_member is enabled and net.link.bridge.pfil_bridge is disabled.