"Multiple ifaces match the same network"-Problem with standard WAN+LAN Setup

[d39FAPH7]

Hi,
on a fresh 25.1.3-amd64 install i have the following setup:
ISP-Router with own address 192.168.1.1 and 192.168.1.0/24 Range => WAN Interface on OPNsense set to DHCP. LAN on OPNsense is 192.168.1.0/24.

Although "Block private networks" is checked, i can access the ISP Router which i think is strange plus as the ISP Router runs a DHCP Server this creates a "Multiple interfaces match the same subnet" Problem which makes the whole network die after some time. I cannot change the behaviour and IP Range of the ISP Router and as "Block private networks" does not seem to do anything i probably need to create manual block rules but i'm not certain which one's.

Can anybody help me out? Thanks

[Fabian Wenk]

Use another subnet in your LAN, e.g. 192.168.2.0/24.

[d39FAPH7]

that's not possible, sorry. i switched from pfsense and this setup worked without a problem for the last 6 years, so there must a solution with filtering.

[EricPerl]

Unless you use OPN as a transparent bridge, you have to use non overlapping subnets on LAN and WAN.

[d39FAPH7]

to be a little more precise: the WAN interface with the ISP Router normally bridges me public IP address. during boot, failure, 24h disconnect, automatic firmware updates etc it resides in 192.168.1.0/24 and during that time this tears my network down. so actually i don't need access to private networks on wan. i guess i could just block that completely.

why i can't change my local net: i have paper cutting machines from the 90s with software from hell that once worked via rs232 that i don't have access to anymore. so these IPs are fixed forever.

[patient0]

to be a little more precise: the WAN interface with the ISP Router normally bridges me public IP address. during boot, failure, 24h disconnect, automatic firmware updates etc it resides in 192.168.1.0/24 and during that time this tears my network down. so actually i don't need access to private networks on wan. i guess i could just block that completely.

Out of curiosity: how did you solve it on the pfSense, the two-192.168.1.0/24 network situation?

Maybe a firewall rule on LAN would help, like:

Interface LAN, source 'LAN subnets' -> destination 'not LAN subnets' => allow

This should prevent any 192.168.1.0/24 traffic from going beyond the LAN interface.

[d39FAPH7]

Thanks, i wil try that. Would the following rules also be appropriate?

Action: Block
Interface: wan
Direction: out
Protocol: any
Source: lan
Destination: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Action: Block
Interface: wan
Direction: in
Protocol: any
Source: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
Destination: lan

To the pfSense situation i can say that this just works without any additional rules or config. I guess that the "Block private networks" checkbox does what it says on pfSense while on OPNsense it seems that this does nothing or is legacy?

[patient0]

I'm unsure about the WAN out rule, maybe already NAT-ed and they all are 192.168.1.0/24, WAN in should really not be necessary if you checked "Block private networks" on the WAN interface.

The rules look basically the same on pfSense and OPNsense on the two systems I checked, when "Block private networks" is checked.

Code Select Expand

# pfSense (/tmp/rules.debug)
block in log quick on $WAN from 10.0.0.0/8 to any ridentifier 12001 label "Block private networks from WAN block 10/8"
block in log quick on $WAN from 127.0.0.0/8 to any ridentifier 12002 label "Block private networks from WAN block 127/8"
block in log quick on $WAN from 172.16.0.0/12 to any ridentifier 12003 label "Block private networks from WAN block 172.16/12"
block in log quick on $WAN from 192.168.0.0/16 to any ridentifier 12004 label "Block private networks from WAN block 192.168/16"
block in log quick on $WAN from fc00::/7 to any ridentifier 12005 label "Block ULA networks from WAN block fc00::/7"

# OPNsense (/tmp/rules.debug)
block in log quick on vtnet0 inet from {10.0.0.0/8} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
block in log quick on vtnet0 inet from {127.0.0.0/8} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
block in log quick on vtnet0 inet from {100.64.0.0/10} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
block in log quick on vtnet0 inet from {172.16.0.0/12} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
block in log quick on vtnet0 inet from {192.168.0.0/16} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
block in log quick on vtnet0 inet6 from {fc00::/7} to {any} label "45afd72424c84d011c07957569151480" # Block private networks from WAN


... which makes the whole network die after some time ...

Can you maybe ellaborate what "network die after some time" means?
They can't access the internet while the ISP router has it's mood anyway, yes? Are they not able to communicate with each other anymore?

[d39FAPH7]

Can you maybe ellaborate what "network die after some time" means?
They can't access the internet while the ISP router has it's mood anyway, yes? Are they not able to communicate with each other anymore?

i can barely access the OPNsense then. i get timeouts or the webinterface loads only partially. The ISC DHCP server server collects "Multiple interfaces match the same subnet: igb1 igb3" / "dhcp.c:4164: Failed to send 300 byte long packet over igb3 interface" / "lease 192.168.x.x: no subnet" / "Network is down" errors and then dies. ISC DHCPv4 Server gets red under Services, which means it crashed or shut itself down.

[patient0]

I see, the error itself is not suprising. Suprising is that pfSense does handle it more gracefully.

On pfSense 2.7.2 I do see the same errors in the logs regarding the "Multiple interfaces match the same subnet", makes sense.
But "dhcp.c:4164: Failed to send 300 byte long packet over igb3 interface" / "lease 192.168.x.x: no subnet" sound pretty bad.

On OPNsense, does igb3 still have an IP address (I assume 192.168.1.1?) and is up when the error "dhcp.c:4164: Failed..." is logged?

[dseven]

You're trying to solve a routing problem with filtering - that's unlikely to be fruitful.

Do these paper cutting machines need to be able to reach the internet? If so, are they hard-coded with a gateway address too? What is it? Do you need to be able to connect to these cutting machines from other LAN hosts?

Trying to use the same subnet on both WAN and LAN is going to be problematic, as already stated. If you really have two immovable objects, some creative routing solution is needed...

[EricPerl]

Precisely. A look at the Interfaces > Overview would indicate interfaces with overlapping routes.

So the ISP router is normally in bridge mode but somehow temporarily reverts back to a mode where it acts at least as a DHCP server with stock settings???
For example during its boot process???
Boot with stock settings, read config at some point, reconfigure network with that config? Seriously?

Let's assume for a second that it's not configured as a bridge, but with a custom LAN subnet.
Would it really start with the stock subnet and reconfigure to the custom one at some point?
It's hard to believe it could be that bad.

All I'm saying is that there might be a way to get that router to start with another range. Anything but stock 192.168.0.0.
Personally, I would contact the ISP to get proper HW.

[d39FAPH7]

@EricPerl: Yes, you are absolutely right. This is complete crap but actually you can be glad these days if a cable provider like Vodafone gives you the option to have a public IPv4 address in bridgemode at all and not only double-nat with dualstack etc.

If you run this modem/router in normal mode you can of course adjust the ip-range and other settings you would expect from a consumer-grade router. If you want bridgemode you set this at the webinterface of the provider website and then the firmware gets remotely exchanged in a 30min process to the bridgemode firmware which then has zero options. I know it's crap but it is how it is and the good news is that with the firewall rules i posted above everything seems to work now.

[d39FAPH7]

I see, the error itself is not suprising. Suprising is that pfSense does handle it more gracefully.

On pfSense 2.7.2 I do see the same errors in the logs regarding the "Multiple interfaces match the same subnet", makes sense.
But "dhcp.c:4164: Failed to send 300 byte long packet over igb3 interface" / "lease 192.168.x.x: no subnet" sound pretty bad.

On OPNsense, does igb3 still have an IP address (I assume 192.168.1.1?) and is up when the error "dhcp.c:4164: Failed..." is logged?

thanks for helping me with own testing! i remember that in the dashboard the interface oscillated between red and green or up/down. I deployed the rules that i posted obove and since then i cannot see any more errors. I'm not quite sure yet if this is because of those rules or nothing happened with the isp-router in the last 24hrs (although i rebooted it and a 24h disconnect happened last night)

[EricPerl]

I would think routing comes first, then filtering takes place. FW rules are not going to influence routing.
Whether traffic is blocked by FW rules or going to the wrong interface is going to produce the same result: broken communication.

Do you have issues with double NAT? likely an inbound scenario.
As presented, stable double NAT seems less impactful than this bridging mess.

I'm not sure why the ISP would care whether their equipment is used as a bridge or regular router.
It won't see much of a difference outside your house.