OPNsense Forum

OPNsense – Accessing ONT / Modem Management Interfaces (Complete Guide)

I know that there are existing guides to do this, like this (https://forum.opnsense.org/index.php?topic=36936.0), yet those threads have become quite cluttered.
This guide does not want to take away from these efforts, rather expand them for a complex edge case that warrants a new guide, so here goes:

---

Basic Requirements

First off, there are some basic requirements for this to work:

• You must not block RFC1918 IPs on the OPNsense interface connected to the ONT for obvious reasons.
• Your ONT's (or modem's) management IP must be outside of any of your local networks, including remote VPN sites. This is why you should never use some well-known network ranges that ONTs often use (also covered here (https://forum.opnsense.org/index.php?topic=47099)).
• Some ONTs shut off management access once they establish internet access (i.e., O5 state). Nokia ONTs only react to ARP, but neither ICMP nor IP access works once connected on the fiber side.
• You most probably need outbound NAT to access the ONT because it is statically configured and does not have a default gateway. By using NAT, the translated IP the ONT sees lies inside its own local network, so it can respond correctly. You could theoretically install a route via OPNsense instead, but that does not work for all ONTs. Outbound NAT is the more general solution.
• You need a firewall rule allowing access from your management client(s) to your ONT's management IP.

In what follows, I assume 192.168.100.1 is the ONT management IP and 192.168.100.2/24 is the OPNsense interface IP. Adjust as needed for your setup.

Important warning: Some providers (e.g., Deutsche Glasfaser) block your internet access for a few minutes if they detect traffic to RFC1918 or BOGON IPs outside your networks. Potentially, this may even be true for IPv6 ULAs, if you use those.

• This can happen if devices (Fritzboxes, IoT devices) attempt to reach hardcoded RFC1918 IPs that are not local.
• Such traffic goes out via your ISP router and triggers provider protections.

You cannot simply block RFC1918 on the WAN interface because it violates requirement a).

I like to have an "out" rule on the WAN interface to suppress traffic to RFC1918 destinations, but that is not so easy sometimes...

---

Two Main Cases

You have two separate cases if you want to enable ONT (or modem) access:

Easy Case: WAN interface ≠ ONT interface

You have the actual WAN interface on a separate interface than your ONT. 
This applies if your WAN uses either a VLAN, PPPoE, or both.

In this case, you can assign the ONT interface to the management subnet, because the interface is not being used otherwise.

So, you simply configure the ONT interface like this:

2026-02-03 11_39_28-[ONT] _ [LOCAL_VLANS] _ Interfaces _ OPNsense.mgsoft — Mozilla Firefox.png

This is the outbound NAT rule (you can use it via manual or hybrid NAT):

outbound_nat.png

Now for the question on how to block WAN traffic for RFC1918 destinations - this is easy in this case, because the rule applies to WAN only (and not to ONT):

2026-02-03 13_32_39-WAN _ Rules _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png

And lastly, the firewall rule to allow management clients to access your ONT (in case your LAN does not have an "allow any" rule):

2026-02-03 11_34_33-LAN _ Rules _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png

---

---

Complex Case: WAN interface = ONT interface

This is when your WAN interface is the same as the management interface (often configured via DHCP). 
You must assign a second IP in addition to the DHCP address, using a Virtual IP.

Now for the question on how to block WAN traffic for RFC1918 destinations.

Apparent solution: Use an "out" firewall rule to block all RFC1918 traffic, but create exceptions for your ONT network.

Allow "out" quick from any to 192.168.100.0/24 
Block "out" quick from any to RFC1918 

This will pass outbound packets, but replies may not return unless Disable reply-to is enabled, because the resulting rules in /tmp/rules.debug would show:

Quotepass in quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to {192.168.100.0/24} keep state # Allow ONT access 
block out log quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to $RFC1918 # Never expose internal IPs

Correct approach: Enable Disable reply-to in the advanced rule options for both allow and block rules:

Allow "out" quick from any to 192.168.100.0/24 with disable reply-to 
Block "out" quick from any to RFC1918 with disable reply-to 

Another method: exclude the ONT network from the RFC1918 block. 
Note: You cannot use an exception in the RFC1918 alias. You must manually list all subnets except the ONT subnet.  On the other hand, you need no "disable-reply-to" in your (single) rule.

Example alias "RFC1918_WITHOUT_ONT":

10.0.0.0/8 
172.16.0.0/12 
192.168.0.0/18 
192.168.64.0/19 
192.168.96.0/22 
192.168.101.0/24 
192.168.102.0/23 
192.168.104.0/21 
192.168.112.0/20 
192.168.128.0/17 

Them use the new alias in your block rule:

Block "out" quick from any to RFC1918_WITHOUT_ONT 


---

Actual steps with screendumps

So, to configure for the complex case, first create the virtual IP:

2026-02-03 12_29_31-Settings _ Virtual IPs _ Interfaces _ OPNsense.jmg — Mozilla Firefox.png

Do not forget the outbound NAT rule (you cannot use "Interface address" for the NAT address because of the virtual IP):

outbound_nat2.png

Again, you can use either hybrid or manual mode for this.

Also, unlike in the easy case, you cannot use "ONT net" with a virtual IP in your client access rule:

2026-02-03 12_42_16-LAN _ Rules _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png

The first (pass) rule discussed above will look like this:

2026-02-03 12_53_01-WAN _ Rules _ Firewall _ OPNsense.jmg — Mozilla Firefox.png

The second (block) rule is this and it has to be placed after the pass rule:

2026-02-03 12_56_50-WAN _ Rules _ Firewall _ OPNsense.jmg — Mozilla Firefox.png

The alternative method uses just a single block rule with a modified alias instead of the two rules:

2026-02-03 13_05_10-Aliases _ Firewall _ OPNsense.jmg — Mozilla Firefox.png

and no advanced options (i.e. no explicit disable-reply-to):

2026-02-03 13_00_45-WAN _ Rules _ Firewall _ OPNsense.jmg — Mozilla Firefox.png

As outlined by @Maurice, there is yet another way to keep RFC1918 IPs from leaking outside your WAN gateway - thereby eliminating the need for "out" block rules or exceptions for that.

You can define NULL routes for RFC1918 and ULA ranges like so:

2026-02-03 18_41_52-Configuration _ Routes _ System _ OPNsense.jmg — Mozilla Firefox.png

Note, however the warning on that page:

QuoteDo not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.

Why that works:

You create routes that use your localhost interface(s), i.e. they end on your OpnSense itself, so packets using them will never exit via the default gateway. However, you cannot set priorities on these system routes. This is not neccessary for as long as any rules for your local interfaces are more specific than these.

As an example, say your LAN is configured to use 192.168.4.1/24. When you look at the routing table, 192.168.4.0/24 is more specific than 192.168.0.0/16 and thus will have a higher implicit priority.

Caveat: This scheme would severely break if you ever created an interface that covers the whole of one of these NULL routes, e.g.: 10.0.0.0/8. It only works for as long as your interfaces are using less general subnets.

placeholder

There's another and - in my opinion - better approach for preventing traffic with private destination addresses from being routed to the ISP:
Create null routes for all private address space. This will blackhole all private destination networks for which no higher priority routes exist. No firewall rules needed.

null routes.png

And if your ONT has 192.168.100.1, I would configure OPNsense with 192.168.100.2/30 (not /24).

Cheers
Maurice

Quote from: Maurice on February 03, 2026, 05:21:48 PMCreate null routes for all private address space. This will blackhole all private destination networks for which no higher priority routes exist. No firewall rules needed.

W00t! Good old Cisco IOS memories ...

Definitely going to implement this. Thanks!

I thought that's how everyone does it everywhere anyway. Assumptions... 😅

Cisco IOS has a Null interface - the idea to do it on OPNsense with Loopback did not occur to me.

I buy this, smilingly, because I actually already had those NULL routes, myself. I added it, together with a caveat...

BTW: The Null4 and Null6 gateways do not have to be created manually, they are already present.

Is it a bad idea to use both the Null routes and blocking rules together?  As I understand it the routes are more reliable even if the f/w is offline or unavailable (such as in early boot) but the rules provide valuable logging.

Thanks for combining the tutorials.  This'll be my reference next time I clean up my ruleset for the modem access.

The firewall rules - as given - handle only RFC1918, the null routes are also applicable to ULAs, should you use them.

You need only one or the other, but still you can use both. For the null routes, I gave a caveat and the firewall rules can be a little complex, which is why I explained them in detail. Also, IMHO, the null routes are less obvious/transparent if you do not know they exist.

It boils down to a matter of taste.

You can also null route your static prefix(es) if you have any. That prevents OPNsense from routing destination addresses you are not (yet) using back out to your ISP via the default route.

... and for dynamic prefixes (DHCPv6 PD), OPNsense adds a null route automatically (since 23.1).

https://github.com/opnsense/core/issues/3304

Never noticed it before but yep, it's there.  I get a dynamic PD /60 and link#5 indeed is my loopback device.

null-route-dhpcv6.png