Automatic renumbering of LAN in case of conflict with WAN

By that logic ANY router I buy of the shelves will have a default IP address and would therefor not qualify for "correctness/reliability" ?? Your suggestion to even "randomly" assign a new IP (range) every boot. On the same logic even "openwrt.lan" might be wrong: I could be connecting a router behind another OpenWrt device which also is associated with "openwrt.lan".

All of these "features" are bloating the basic OpenWrt. I am still annoyed EVERY TIME! by the "feature" that when I change the basic IP address and don't change it fast enough in my browser it will revert back the change! My simple workaround is NOT to use LUCI and just SSH into the router and get it done properly. I can probably find lots of examples where there is a lot left to be desired on the GUI part.

So instead of automatic renumbering the LAN in case of conflict with WAN, why not focus on things that are actually broken or (still) not working properly? (Which doesn't exclude that fact that we could change the default IP to a less used one as I suggested).

One of my TODO projects is to have a better DSA GUI switch interface (more similar to the old one) and to allow users to easier manage VLAN etc.

1 Like

Strongly disagree.
Firstboot only, and then maybe an opt in configuration item that can be useful for roadwarrior setups.

No way should it be a default behaviour at all times

4 Likes

I'm wondering.
In the flow of logic, I read

Why is it a problem here, to keep this as the "default" behaviour, after every boot ?
Just in case, the router is connected to another LAN.
NOT to do it on every boot, means, its not "Plug and Play" any more.
The user then needs to know about the routers internals. Which I do not consider a good principle, if it can be avoided.
So, again, where is the problem here ?

Eh...doesn't that go against the whole OpenWrt principle: The freedom to configure and install user/use-case specific packages. Doesn't that imply that the user needs to know about the routers internals??

I will appreciate, first to receive answer to my question. Then you can expect an answer to your question, of course.

Ok: you started with a use-case of daisy chaining two routers. Normally one would connect LAN (device 1) - LAN (device 2). Disable DHCP on of them. That doesn't answer the question about automatic renumbering as the problem doesn't exist anymore. Further more it will eliminate double NAT.

To have an OpenWrt router check and renumber its own LAN on every boot if it detects a conflict with the WAN connection is not something I would like to see as standard feature. What if the "second" router boots faster than the first? It would have to wait to hand out IP addresses until it has a WAN connection. Leaving the device unreachable to even troubleshoot "why" there is no WAN connection. The "first" device is also running OpenWrt, so that one is also not handing out any IP addresses until the WWAN connection is establish.

Another issue with renumbering the LAN every reboot is "Static Addresses". All those would be invalid. How would you handle that in a script?

1 Like

Not necessarily. More logical from users standpoint of view is LAN(1) -> WAN(2). I also do it this way, although (or because ?) having a few years expirience already. Double NAT usually not a problem nowadays.

And ? 2'nd router can not connect to internet, anyway. Regarding maintenance, in "Basic Logical Flow" there is a timeout, to bring up LAN, in case WAN comes not up. So you can login.
Thus, until now your arguments do not really apply.

Sorry, I do not understand your last paragraph. Please, elaborate.

I wonder about this, will the system know if multi interface applies and what does it do then?
And if no interface called lan exist to begin with?

I still feel that if this function is made is should be default OFF.
Probably 99% of the world doesn’t even have this problem if the ISP does their job to begin with.

Wouldn’t it be better to block the whole wan connection if the system feels a conflict with the address it is given by upstream DHCP server. Instead of messing around inside the whole internal network.
Then the user will have to log in and fix the problem.

Wow... quite the discussion!!

I'll try to address comments here. For the record, I was not fond of this idea at first, but I came around to see the value, especially for novice users. And it is really important to note that my proposed solution is not intended to address every possible permutation of network conflicts... it just tries to handle the most common WAN/LAN conflict scenario that negatively affects new/novice users.

I'm not 'attached' to this, though -- if the OpenWrt community (or maybe more accurately the primary dev team) deems this to be a risky/problematic/confusing feature and it doesn't get implemented, so be it.

For this to work, I think that it needs to be on at all times until disabled. If it only runs on "first boot" it means that the feature won't be useful to many new users. Example: a new user doesn't connect a WAN at first, but sets up things like wifi and time zone or whatever, but does not change the LAN. The user llater connects WAN but has a conflict... if the detection only happens for first boot, the (novice) user may not understand why things are not working properly and they will still come to the forum with this basic question. That is what we are trying to help resolve.

I think that there would be a lot of pushback to change the default OpenWrt LAN address... in large part because it is known and well documented everywhere on the web -- well beyond the scope of OpenWrt.org. Not to say that we should live with dogma forever. But this idea of conflict detection would allow the default to remain the same while offering a (deterministic by default) alternative address if a conflict is detected.

I'll be honest that sometimes I have this feeling, too. But then I remember that we all had to learn this stuff at some point. And there are many reasons someone may use OpenWrt, even if they are a novice user. If I look back on my own progression of networking knowledge, it is clear that I had to use more advanced environments (OpenWrt, EdgeOS, Unifi, others) in order to have the features available to learn in the first place... I surely made lots of mistakes and had lots of gaps in my knowledge... but by using these platforms, I learned a ton. The idea here is to alleviate one of the common pain points that happens for new/novice users.

The logic I laid out would either use the existing default (192.168.1.1/24) or a known/default alternate (say 10.9.8.1/24 as an example), based on what is happening upstream. If there is no conflict wit the current WAN address/status, the address would not change. Therefore, it is not changing randomly on every boot. The only 'random' feature here would be if engaged by the user for a situation like the road warrior context because the upstream networks are unknown, may change frequently, and there could be several concurrent connections (cellular, wifi wan, wired wan, VPN).

That could happen. But in the default state, the DHCP issued DNS resolver would be the router to which a client is directly attached, and that resolver should theoretically not look upstream since it will (by default) have the local entry for openwrt.lan.

As I mentioned earlier, IMO the problem could very easily occur after the first boot has happened. Keep in mind -- the proposed logic is to do nothing unless there actually is a conflict.

We should always remember that people who are new to OpenWrt (and/or networking in general) may be using this platform to learn. Some people just want to have a more secure alternative than the vendor supplied firmware. Others want to extend the functionality -- sometimes with basic config changes or simple package installations that are not available in the vendor firmware. Still others want to dive in deep. Not everyone knows the internals, but they can/will learn it as needed.

I agree with @reinerotto here -- many (especially novice) users connect LAN(1) > WAN(2) and end up with a conflict. That is what we are trying to address here.

The default configuration always includes an interface called lan. This is the context for which I am proposing a solution. If the user has changed this interface, or if they have multiple LANs configured, it is probably a safe assumption that they have enough networking knowledge to understand the issue with overlapping subnets. Further, if you're dealing with multiple networks, you may have numbered them in a particular way, so we don't necessarily want to start changing those other networks.

If it is default off, it defeats the purpose of trying to help novice users get 'unstuck' with a cascaded router situation that isn't routing. Obviously this could just be an optional package instead -- maybe implemented within TravelMate or something similar for the road warriors. However, this is intended to solve the problem of the cascaded routers for the newbie.

If you mean that the ISPs themselves aren't directly issuing addresses in the 192.168.1.0/24 network -- yeah, that's not a problem. ISPs should always be using public IPs or CG-NAT. Some use the 10.0.0.0/8 range (even though they're not really supposed to), so again, no conflict. But many ISP supplied routers use this subnet. So, if a new user plugs an OpenWrt router into their ISP router (a device that may be required and may not have a bridge mode option), that is when they will see the problem.

Again, remember the proposed logic only changes things if there is actually a conflict. Otherwise it does nothing, so there is no downside to having this enabled by default, IMO.

1 Like

I am just one of those users that hates when software makes magic decisions on my behalf, no matter how well intended. If I decided to configure WAN and LAN on the same IP segment, I want OpenWrt to respect that decision, no matter the catastrophic consequences.

Besides, this whole idea is only valid as long as there is one WAN interface, named "WAN", and configured as a DHCP client, plus one LAN interface, named "LAN", and configured as a DHCP server... OpenWrt should not assume that the current configuration matches the default configuration, and can make changes based on assumptions about the default configuration.

This is why I think it would be a bad idea to make unsuspected changes to the configuration, after the user has configured the router to meet their needs.

2 Likes

Call it "first boot", "until disabled", or "until properly configured", and I think we both agree on the concept.

Sure, but how does the system determine that it has been "properly configured?"

I suppose one way it could work would be to run the script on the first wan up after first boot, and at the end of the script it would automatically disable itself unless it was enabled explicitly by the user. This might not be ideal as I could imagine a situation where someone might preconfigure a device to deploy at a friend/family member's house and run into the issue when they do that, but maybe all we really need to worry about by default is the first time the wan comes up.

Thoughts?

So if the idea is to make OpenWrt more click-and-play: have a look at X-wrt. Designed to have more mouse-click friends novice apps. See as example the Luci-app-wizard here: x-wrt. It runs at first boot and asked how the user is connected to the internet (DHCP, PPPoE or Static). You could build on that and have the LAN side change from default after the WAN comes up. Have a tick-box (or something) to have it run again on reboot or not.

I understand there is a great need to new users to have a nice bling-bling eye-candy filled GUI.I am not a fan so I would at least hope that we would have different flavours: One "core" version without all those bloatware and a Full version, which even might include Wireguard or OpenVPN, some NFS packages for devices with data or usb etc. We will have to raise the bar again on supported devices: 32MB flash and at least 256 MB RAM...but...that will improve the software quality :slight_smile:

For improvement of software I would like to vote for better DSA support: Why is "brctl" still the default over "ip-bridge"? The package size is the same but "brctl" is depreciated for a few years already and is missing functionality to properly setup a DSA bridge. Some goes for various "ip" command from BusyBox: why not replace all those with "ip-full". After all OpenWrt is a router OS first so I would expect those basic tools to be installed by default.

Back on topic: How many users are daisy chaining a device (improperly WAN-LAN; which should be fixed by changing the physical cable to another port / reassign the WAN as part of the LAN (its only labeled/color coded on the box, its just a port from the switch point of view).

There will always be use cases which are not covered by OpenWrt "at first boot": A lot have been mentioned before: static IPs, Multi WAN, Link Aggregation, VLANs, multiple bridges, various (VPN) tunnels that are not configured by default.

I don't think this is really at the core of the issue, personally. Yes, a wizard setup might have an auto-detect feature, but such a broad UX change is not required to implement subnet collision avoidance.

I have opinions on this (as an OpenWrt enthusiast), but this is tangential to the purpose of this thread. If you'd like to hear opinions on this idea (mine and others), break it out into a separate thread.

I don't have numbers. But I do know that we see this as a fairly regular topic for new and novice users who can't understand why their OpenWrt router (sitting behind another router) is not providing internet.

And it is deeper than just the physical labeling of their device. Some users want OpenWrt but are stuck with a mandatory ISP provided router. So they put connect a router running OpenWrt to their ISP router (LAN(1) > WAN(2)) and put their entire network behind the OpenWrt router (2).

Those who are aiming to use the device as a dumb AP and/or have all ports active on the switch and all members of the same network will be making other changes anyway.

Yes. In my proposal, I tried to limit the scope of the feature for 2 reasons: simplicity of design, and the fact that more complex setups -- and really the users who are configuring said setups -- likely don't need it (further: those users would likely hate the feature). This is really just aimed at the simple default installation running LAN(1)>WAN(2) behind another router -- a situation that tends to trip up many novice users. And, of course, some slightly more advanced features for road warriors, but still somewhat limited.

I think, the spread of "Open Source Software" will be encouraged, in case "it simply works". Every step, to make it more enduser-friendly helps here.
The Closed Source vendors must sell their stuff, badly trying to achieve real "plug and play". No reason, not to use the same approach. Unless the aim is, to keep openwrt for all the sophisticated users only who "are in the know".
Thus, the ones "who are in the know" should be able to remove the automatic renumbering of LAN during every boot, in case not appropriate.

I'm not opposed to a more user-friendly setup process. In fact, that is why I came around on this topic (l was somewhere between lukewarm and against the idea at first). All I was saying is that this specific idea can be implemented without the need for a large UX change (i.e. making a wizard). Although I would say that a wizard like that could be good for novice users, and this feature that we discussing in this thread would make sense to be integrated into such an effort. But this feature doesn't need to be predicated on, or wait for, the development of a wizard.

My opinions on the matter had really to do with the different flavors -- that is a discussion for another thread.

The aim is "everyone should use OpenWrt"! But: before the end-user upgraded to OpenWrt, their device couldn't do what you are suggesting. Making the UX/UI enduser-friendly is out of the scope of this thread, but we seem to end up on that anyway. The problem is: a lot of users don't even really know why they upgraded their device. They just "read somewhere" OpenWrt - SQM - faster internet - better gaming bla bla. Which it can do, but not without some serious configuration. They expect "magic". Their OEM device had some VPN standard, it had Guess-Wifi standard it had Network Sharing of their USB Harddrive standard. All those thing can be done and need to be configured and very likely packages need to be installed for that. OpenWrt is NOT an OOTB solution.

Look at: Windows - MacOS - Linux. All of those "simply work". But for a lot of people going from a Windows PC to a Mac is "a big step" EVEN when the Mac "Simply works" and everything is nicely done with lots of eye-candy. Their Ubuntu/Debian/whatever experience is even worse: "With freedom comes responsibility".

So maybe we need to figure out a way to better educate users. I have no good solution for that btw.

2 Likes

Just done some testing, with mixed results. I placed a second OpenWrt device (secondary) on my LAN, behind the primary OpenWrt router (primary). Both had identical numbering on their br-lan interfaces, meaning that the IP address allocated by "primary" to the wan interface of "secondary" was inside the range of secondary's br-lan interface.

Surprisingly, secondary was quite able to reach upstream addresses, when referred to by IP.

Resolving names was not possible, because /tmp/resolv.conf.auto had primary's IP address (as expected), but this was also a local address, and hence turned into a loop. i.e. name request hit secondary's localhost (according to /etc/resolv.conf), entered dnsmasq, which tried to resolve against "upstream", but sent to its own br-lan IP, hitting dnsmasq again, making a loop. Fortunately, dnsmasq detects this, resulting in:

Thu Dec 16 00:18:26 2021 daemon.info dnsmasq[2104]: 3 127.0.0.1/39444 query[A] google.com from 127.0.0.1
Thu Dec 16 00:18:26 2021 daemon.info dnsmasq[2104]: 3 127.0.0.1/39444 config error is REFUSED

I could ping by IP address, though, and the upstream gateway was correctly resolved. There did seem to be a lot of packet loss, though. I could also reach e.g. google.com on port 80, and get a response to "GET /", although it took a long time, for reasons I could not determine.

I wonder whether there might be breakage due to ARP at some point. i.e. who-has 192.168.1.149 tell 192.168.1.1, but the response goes to secondary's br-lan?

I also started investigating lxc as a solution for containerising the br-lan side of things, with an intermediate network. I installed it on my EdgeRouter X, but have run into a lack of knowledge of how to actually set lxc up. It seems to me that I would only need an overlay for /etc/config (or maybe /etc/ as a whole, to control which daemons/services are run inside the container vs outside). I have read that there may be a problem with procd trying to create /dev inside the container, though, so there may be more complexity than I realise. I do realise, though, that this may be a sledgehammer approach to cracking a nut. As a reminder, the idea here is to use an intermediate network (which was originally suggested as 169.254.0.0/16, but could be randomly renumbered whenver the upstream network conflicts with anything) as a way of separating the wan network range from the br-lan network range. A veth network would be used to escape the br-lan container, and I guess that this could be DHCP assigned as well. While there would be double NAT involved, it would essentially be a "DMZ"-type scenario, where any incoming packets to the wan IP would be forwarded to the IP address assigned to the veth inside the container.

Ignoring my containerisation approach, I think there are a couple of things we can do as a first pass. One, if a conflict is detected with the default br-lan IP address and an assigned WAN address, make that known to the user by displaying a message prominently in the LUCI UI. Ideally, before login, even. And provide instructions on what to do about it. "Choose a new range for the LAN interface, then reconnect to Ethernet or Wifi to get a new DHCP allocation in the new range." Even provide a button to do it for them automatically, perhaps.

Second, make the action taken on detection of conflict configurable. One option is the message above. Another option might be to automatically choose a random (or known alternate) network range that does not conflict. Another option might be to run a shell script to fix things up as desired by a sophisticated user.

@psherman Thanks again for writing up the idea. I mentioned it at the OpenWrt Admin meeting just now, and there were two (positive) answers:

  1. This is more a political, and not so much a technical decision. It changes the "way OpenWrt behaves" (possibly for the better) and thus needs scrutiny.

  2. However, it was seen that it might be valuable, so the sense of the meeting was to create an RFC (your post of 9 Jan 2022 is a good start). It probably should be a new topic on the forum, then it can go to the openwrt-devel and openwrt-admin lists for further discussion.

It isn't a slam-dunk for acceptance, but the group was definitely open to the suggestion. Thanks!

Real-time notes from the meeting are at: https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD

4 Likes