How can I configure an interface to have multiple IP addresses and connected routes? Examples of what I am trying to do:
1. WAN interface has a static (routable) IP, but the modem that is attached to the WAN port exposes its management interface on 10.1.0.0/24, and I want to get to that from the LAN side.
2. LAN networks get their IPv6 via prefix delegation, but I would also like to statically assign a ULA (a block inside of fd00::/8) on these interfaces.
Quote from: jmw on July 27, 2025, 06:11:25 AM1. WAN interface has a static (routable) IP, but the modem that is attached to the WAN port exposes its management interface on 10.1.0.0/24, and I want to get to that from the LAN side.
That should work out of the box. OPNsense doesn't block outbound connections to RFC1918 addresses.
My modem has a 10.x management interface but I have no problem reaching it from my 192.168.x LAN. As long as you aren't inadvertently blocking it with a rule, it should take the default route and reach your modem via the WAN interface (post-NAT).
Quote2. LAN networks get their IPv6 via prefix delegation, but I would also like to statically assign a ULA (a block inside of fd00::/8) on these interfaces.
Have you tried IP Aliases under Interfaces->Virtual IPs?
I did something similar for my WG site-to-site setup with dynamic DNS. I'm using unmanaged RAs for IPv6 SLAAC and this allows all of the LAN clients on those networks to generate ULA IPs under the designated /64 prefix.
Unless you override it (which I haven't tried) the OPNsense interface itself will auto-generate a stable IPv6 address under the same ULA prefix using the EUI-64 of the parent interface.
IP Alias.png
Guides for accessing a modem interface on WAN:
https://forum.opnsense.org/index.php?topic=33497.0 - using a separate interface
https://forum.opnsense.org/index.php?topic=36936.0 - using a VIP (virtual IP)
If you access the internet using PPPoE then accessing it over the PPPoE parent interface would be the easiest way.
From a L2 L3 perspective, as long as your FW routes the rfc1918's that are not local to the fw via DFG, the modem gets a rfc1918 dst IP. All the modem devices on ISP service will not fwd rfc1918, so it should just reply back. However, make sure your fw WAN(inbound) config is not blocking rfc1918 source IP.
I don't think the modem actually binds the 10net to it's eth port. As example, my old setup had modem gui iface on 192.168.100.x, but my router never had a local 192.168.100 on it's wan port, so all it could do was fwd to DFG (the modem). Since 192.168.100x was bound locally in the modem, the IP stack there could fwd packets directly to the local process that had bound that IP, typically an embedded web-server.
(https://i.postimg.cc/JhQgwCqq/Screenshot-2025-07-26-224913.png)
Quote from: BrandyWine on July 27, 2025, 07:51:56 AMHowever, make sure your fw WAN(inbound) config is not blocking rfc1918 source IP.
It works for me without any WAN allow rule. 'pf' state tracking should handle this, no?
Std FW rule on LAN is all that is needed.
Return traffic is stateful regardless.
The FW would allow rfc1918 outbound from LAN to WAN, because there's no auto-rule or manual rule blocking that (as long as manual LAN rules allow it, etc). But traffic ingress to WAN is subject to the WAN auto rules. Does the state table override auto rules? That would be odd.
As far as alias iface (aka sub iface), not sure how that helps. Doing a sub iface would just change the fwd'ing from L3 to L2, everything else would stay the same. I still suspect even with a sub iface the WAN auto rule (setting) would (should) block the return traffic when src IP is rfc1918.
The option I referenced is a default protection option. The FW will block inbound on WAN if the src IP is rfc1918 (regardless if there's a egress SYN in state table). If the modem hands out non-rfc1918 to the connected router, then we should never expect to see rfc1918 src IP inbound to FW WAN port. Hence what the setting info explains. It would be better if that setting simply dropped all RFC1918 seen on the WAN port regardless of inbound or outbound (creating a 2nd auto-rule to drop dst rfc1918 on WAN outbound, etc). You might wonder why rules on WAN side, because you might have other rfc1918 local or routable via another iface and we still want the FW to be able to L2/L3 fwd rfc1918's destinations.
You can see this using tcpdump in ssh.
That setting is a auto-rule on WAN. To increase security, add a rule to WAN as "outbound" blocking all the same nets as destination. We often use a LAN rule for allow HTTPS with dst ANY. That's ok but it allows all rfc1918 as dst, and the router will sill fwd using route table, and most stuff will go via DFG. There's really no reason to fwd those packets out the WAN to modem (for most setups of this nature), etc.
(https://i.postimg.cc/6qQTVKH1/Screenshot-2025-07-26-231345.png)
If you need to be local to that rfc1918 net outside the WAN port, then creating a sub iface in that net is ok, you then just need to be crafty with NAT, so when you access that outside net the traffic is nat'd to the sub iface. That would then make all that specific traffic on the WAN wire appear as local traffic. Can you do a sub iface on WAN port if that iface itself is DHCP?
This other forum post about adding sub iface and doing outbound nat works 100%. It leads me to have other questions about fw functionality.
https://forum.opnsense.org/index.php?topic=37682.0
Update: Yeah, OPNsense fw needs a little fixin. It seems that the auto-rule for deny rfc1918 on WAN is overrided by state table. Thats a bad feature. Settings that make auto-rules should override state table.