I have a very similar scenario, in IoT. I will certainly go the udhcpc.user route, as "env" provides the IP and subnet assigned. Both for WAN and WIFIWAN. No need to check for conflict on LTE, as special IP-range used.
No public IP, usually. However, because of special IP-range, for CG-NAT, usually, no conflicts. Unless 2 WWANs in use.
Mobile ISPs around here like to (ab-)use 10.0.0.0/8 for LTE and friends.
Interesting. Which country ?
Thanx. OK, need to take 3rd world IT-infrastructure into consideration, too.
Sure, that would be nice. What would be nicer is having a system that will allow you to just plug it in, and have it work, regardless of the numbering that you encounter. That means less training for the tech on site, fewer setup steps, less opportunity for errors, etc.
And yes, I understand that this is a relatively niche use case (IoT, but also road warrior), but it would still be nice to be able to accomodate it.
So far, the best two solutions I have seen are checking the upstream network range, and renumbering the downstream defensively, and my suggestion of using a transit network, network namespaces and double NAT to isolate the two networks from each other.
Is there possibly a way to (ab)use policy based routing to solve this?
IMO, if such a feature set were to be developed, it should be done as a user-installable package and not included by default. The risk of introducing this as a core function of OpenWrt is that it would make the device's IP address unpredictable, depending on the status of the upstream network. Yes, advanced users would probably figure this out, but it would be even more confusing for a novice.
And then the problem for the novice end up here in the forum to fix…
Or alternative 2:
“I hate OpenWRT it is the worst thing ever and it never works!!!!” or something like that will be spelled.
Yes, there is truth to that. But, imagine if the default OpenWrt address was not deterministic. At least current situation means that the advice is easy and consistent, and they will always be able to reach the OpenWrt router when they connect to 192.168.1.1 (rather than having to explain to them how to find the IP address of their host system to figure out the random address that OpenWrt has assigned itself). And even more confusing would be someone who begins the setup 'offline' (i.e. no WAN connected) and then plugs it into their network and suddenly cannot reach the router because the IP changed without their knowledge.
That happens, too. But I would say it isn't that frequent. We see many more people asking for help when routing isn't working because of double-NAT (overlapping subnet) than we do swearing off OpenWrt.
Also, I am not aware of any routers that will dynamically change their LAN addresses based on an upstream conflict. The problem of overlapping subnets is true for all routers, regardless of brand or OS. So when you mention that, usually people realize that it isn't something to hate about OpenWrt.
Just my 2 cents.
Coming very late to this topic... A month ago, I made a similar request:
- LAN interface come up on a subnet that isn't on the (DHCP-assigned) WAN subnet
- Use mDNS and ...
- Tell newcomers to connect to
That completely circumvents the hassles for a new user of OpenWrt needing to understand what their problem of having to figure out what all those subnets are about...
Boom. there it is. This had not occurred to me.
Okay, I concede... this could be achieved in a way that makes it easy for novice users and advanced users alike.
Can be done using dnsmasq, as well. Actually, I have systems, where the user must do something similar, anyway. I.g. to configure credentials for WIFIWAN. But I introduced a DNS-name instead of 192.168.1.1 more for reasons of very old, very good, but obviously forgotten programming style: Do not use absolute values, but "parameters or symbols" instead. Which makes maximum sense here.
You are confusing DNS and mDNS:
openwrt.lan- DNS, can be shortened to
openwrt, assuming the client accepts search domains.
openwrt.local- mDNS using a service like umdns, expects the client to resolve mDNS with its own client side service, should work for Linux/macOS clients.
By the way, IPv6 connectivity over LLA/ULA/GUA should not be affected.
However, this does not solve the routing issue with overlapping LAN and WAN IPv4 routes.
Although custom metric on the WAN interface can partially work around the problem.
Correct. But it eliminates the valid argument, not to dynamically change 192.168.1.1 because the user needs to know IP how to access the router via ssh or browser. Consider 'openwrt.lan' a pre-requisite for implementation of any method to solve overlapping subnets by changing the routers IP not to conflict.
Keep in mind that clients using hardcoded or encrypted DNS may not be able to resolve OpenWrt hostname with plain DNS, so in general case the gateway needs to be identified by analyzing runtime network config/status or performing diagnostics with traceroute/tracepath by IP.
Anyway I agree with this. This kind of function will most of the times be more of a problem then help. And a disaster for complex networks if it is default and not easy removable.
And I doubt that so many ISP in the world run double NAT with the end user so we require the whole user base to have a RNG for the IP address since this problem is kind of non existent in this forum.
And all of this is based on the fact that the user only have LAN interface behind the firewall, a RNG IP on a multi interface network gets kind of messy. Not to mention all the clients with static IP on different interfaces that looses there connection.
I’m curious about this? Any explanation about how this would work? I do understand the idea of a route metric being to indicate a “less expensive” or preferred route, while still having an equivalent route via a different interface or gateway, but how would that solve this problem? Doesn’t the less expensive route need to go away before the more expensive route would be used?
The default IPv4 metric is zero, so custom metric on WAN makes it more costly than LAN except for the gateway which would require a separate /32 route.
Sounds good, in general. However, this will interfere with mwan3, or not ?