WAN interface passing to private destinations

Started by glenb2, June 30, 2026, 03:00:03 AM

Previous topic - Next topic
Today at 06:39:20 AM #30 Last Edit: Today at 11:18:00 AM by lmoore
Quote from: nero355 on July 03, 2026, 07:05:03 PMThe same goes for Fibreglass ONTs and xDSL Modems :)

But I was thinking to have something like this :

But then two times each :
- Block Private Networks - Incoming
- Block Private Networks - Outgoing
- Block BOGON Networks - Incoming
- Block BOGON Networks - Outgoing

If your xDSL/ONT modem only has one Ethernet port and if you want the ability to check the status of the modem without interrupting the connection to the Internet, your only choice is to access the modem via the WAN port.

My xDSL modem is a Draytek VigorNIC 132 which is plugged in to a PCIe slot.

Prior to setting up OPNsense as my firewall (January 2021), I was using OpenBSD. With OpenBSD I set up a bridge interface and included re0 (WAN port) and vether0 interfaces as members. The vether interface was configured with the RFC-1918 subnet I use to access the modem's web interface. Doing this allowed the standard outbound blocking rule for RFC-1918 address to be used without impacting access to the DSL modem.

Unfortunately, the vether-kmod port isn't included in OPNsense and won't be a consideration in the future unless the FreeBSD port can be fixed - this seems unlikely.

With OPNsense, I assigned the RFC-1918 subnet to the bridge interface, then set up applicable rules for the modem network.

The preferred method to prevent RFC-1918 leakage is by using the black hole routes, as already mentioned in this thread. It is conceivable that one day, one may encounter a problem and when troubleshooting, the black hole routes may be disabled and they may not be re-enabled if it's forgotten about. The only other mechanism to prevent leakage is to have the outbound firewall rule to block RFC-1918 - I understand ISP's aren't supposed to allow RFC-1918 to be routed normally through their networks.

I have floating rules preventing internal traffic making its way to destinations via the WAN interface. In addition, I've created rules on the WAN interface to block outbound connections from the firewall. This is primarily to prevent connections originating from the firewall itself, otherwise they will be allowed out due to the automatically generated rule let out anything from firewall host itself (force gw).

Blocking outbound connections to bogon networks seems like a good idea. Testing to some of the addresses in the bogons alias, they are being blocked by Q-Feeds. Q-Feeds is the first block rule for my internal networks so it's possible other lists will include them too. However, they aren't being blocked from the firewall itself - time to review and update my outbound rules on the WAN interface.

[Update] - I already had rules to block outbound from the firewall itself so it is fair to say, the other lists I use do not include bogon addresses. I added a rule to use Q-Feeds and it's now blocking connections to bogon addresses which originate from the firewall itself.