Thanx. OK, need to take 3rd world IT-infrastructure into consideration, too.
1 Like
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.
2 Likes
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
OpenWrt.lan
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...
3 Likes
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.
Excellent idea.
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 toopenwrt, 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.
1 Like
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 ?
The specific case we are trying to address is where one OpenWrt router is behind another one (effectively). In other words, the upstream gateway for the second router (192.168.1.1) is the same as the second router’s LAN IP address. I guess that you could do the following?
Metric 0 route for 192.168.1.1/32 dev wan
Metric 10 route for 192.168.1.0/24 dev br-lan
Metric 100 route for 192.168.1.1/32 dev br-lan
Similarly, since wan would be assigned an address in 192.168.1.0/24 say .1.100, you might need to add:
Metric 0 route for 192.168.1.100/32 dev br-lan
Metric 100 route for 192.168.1.100 dev wan
to deprioritize the locally attached IP addresses (wan and br-lan interfaces) over the reachable ones on the attached networks. Will have to spin up a couple of devices to test if this actually works.
1 Like
Perhaps this is being over thought...
There are 3 distinct, never overlapping RFC1918 address ranges:
10.0.0.0/8, 172.16.0.012, 192.168.0.0/16
The logic could be quite simple:
If the current LAN subnet conflicts with the WAN network, select any /24 from one of the other ranges.
In fact, it can be even more simple -- set a preferred and a backup subnet. The preferred and backup have one requirement - they must be from different ranges. That's it. If the preferred conflicts, it moves to the backup. There could be a set of defaults defined by the OpenWrt developers (192.168.1.0/24 probably preferred because of history, any other as backup). The user could then change these. That's all it needs to do.
2 Likes
Ok, that’s reasonable.
Now to deal with the actual renumbering fallout. If there are clients connected to the lan, they need to be told that their IP address is no longer valid. Can the dhcp server inform clients that they should request a new address?
In the process of getting a new address, the clients dns cache should be flushed, and OpenWrt.lan should then resolve to the new address.
No, the DHCP server cannot recall the leases, and the DHCP cannot "inform" clients to request a new IP. DHCP servers can only respond out when there is a discovery packet (the DORA process). So this could present an issue, and it is not one that would be easy to solve directly.
There are a few possible ways to handle it (not complete solutions)...
If the LAN needs to be changed, the router could bounce the wifi and ethernet ports in the process. This would force all clients that have a direct connection to the router to request a new lease.
- this would not solve the issue for devices that are connected to an external switch, or that are connected wirelessly to another AP on the network.
Upon initial boot, it would also be possible to delay the bring-up of the LAN until either the WAN has been issued a DHCP lease or a timeout has occurred (maybe 10 seconds or so)
- this still doesn't address the earlier issue for devices not directly connected to the router
- and it only covers the case where the WAN gets a lease on boot. Connecting the WAN post-boot would have to rely on the bounce method.
But, if we assume that this issue is not going to be encountered frequently -- really just when people setup a new device for the first time (for example in a home scenario) or connect to a random WAN in a travel/road-warrior type environment, maybe there won't be many devices connected (and hopefully all directly attached). After all, in the default configuration of OpenWrt, wifi is disabled, and typically someone will connect a single wired device directly to the router for initial setup.
1 Like
Yes, reboot is reasonable, after determination of non-overlapping nets.
Frankly speaking, that is expected by me, anyway.
However, I have the more complicated case with: VPN, WAN, WWAN and WIFIWAN. So, your proposed "basic" approach will not work.
I am aware already, that for a valid solution I even have to assume 192.168.0.0/24.