Daisy-chaining routers?

[Patrick9876]

I know nothing about the WAN connection between, for instance, a cable modem and a router so this may be a stupid question. Can I put a 2nd router on a LAN port of a 1st router? I'm probably going to soon buy a new router and am anticipating a fairly long learning curve in the configuring process ... especially if I decide to use OpenWrt.
Once configured and tested it will have it's WAN port connected to my cable modem. This is just a temporary configuration.

It would be very convenient to have that router just be another device on my LAN. I will obviously need to have different SSIDs for the WiFi config. And when I set up DDNS on the new router it will advertise a meaningless and unreachable (LAN) address. Those I can cope with. Are there other things I need to be aware of that would may this problematic or impossible?

 

[ColinTaylor]

Can I put a 2nd router on a LAN port of a 1st router?

Yes. This is quite common, especially during the commissioning of a new router. Just make sure that the 2nd router's LAN subnet is different than the primary router's.

And when I set up DDNS on the new router it will advertise a meaningless and unreachable (LAN) address.

Probably not. I don't know about OpenWrt specifically, but a DDNS client will usually determine your external (public) IP address and register that rather than relying on the IP address of the WAN interface.

 

[Tech9]

Can I put a 2nd router on a LAN port of a 1st router?

Yes. It will most likely be in double NAT configuration (or not, some ISP Gateways offer passthrough ports), but you can pre-configure your new network there (with small exceptions) and just remove the old router when ready. The second router has to have LAN IP on different subnet than the first. If your first router is ISP provided Gateway - make sure this ISP allows replacing their equipment with your own.

 

[Patrick9876]

... a DDNS client will usually determine your external (public) IP address and register that rather than relying on the IP address of the WAN interface.

Hmm. That's good to know. Thank you. Assuming I configure the two router's DDNS stuff the same then I won't know if its working on the new router. I'd better provide a different name on the new router. Or I could temporarily use a different DDNS service.

... If your first router is ISP provided Gateway - make sure this ISP allows replacing their equipment with your own.

Luckily, both the cable modem and router are my own so replacing the router won't be a problem. I've replaced/upgraded the router twice over the past ten years or so. But this will be my first non-AUSU router (a GL-inet) and my synapses have calcified a bit so I expect configuring is going to take longer than in the past. I want my old router running my network while I'm struggling/playing with the new one.

 

[Tech9]

Assuming I configure the two router's DDNS stuff the same

The reason I mentioned "small exceptions" above. Services like DDNS, UPnP, VPN Server, etc. you can do after you swap the routers. My advice is to configure the new router with the same SSID/password as the old router. Use temporary SSID just for setting up the new router, then switch back to yours. It will save you downtime especially if you have many IoTs. Otherwise you have to reconnect all your wireless clients. With the same SSID/password you may need to forget the connection and reconnect on few devices only.

But this will be my first non-AUSU router (a GL-inet)

GL.iNet routers have very user-friendly interface. Perhaps easier than setting up an ASUS router. Just read the manual and you're good. The Phone App will have your new router going in basic configuration in a minute, WebUI as usual has more settings.

 

[cptnoblivious]

Hmm. That's good to know. Thank you. Assuming I configure the two router's DDNS stuff the same then I won't know if its working on the new router. I'd better provide a different name on the new router. Or I could temporarily use a different DDNS service.
<snip>

That's what I've done before, set another DDNS name for the 2nd router, see that it's registering properly. When you do the final router swap, you can clone the external MAC of the router you're replacing and you _should_ keep the same external IP. In case that's important to you, I've not bothered in the past, after all that's why I'm using DDNS in the first place

Good luck!

 

[Patrick9876]

The reason I mentioned "small exceptions" above. Services like DDNS, UPnP, VPN Server, etc. you can do after you swap the routers

I have (now leave) UPnP disabled so that's not a problem. I hadn't thought about the VPN server - the only reason I'm using DDNS. I can work on them after I switch routers.

My advice is to configure the new router with the same SSID/password as the old router. Use temporary SSID just for setting up the new router, then switch back to yours. It will save you downtime especially if you have many IoTs. ...

I have all my computers configured to try 2 sets of SSIDs - one set for the current router and one for a new router. That has served me well in the past when upgrading routers. I hadn't thought of IoT devices. Maybe I didn't have any when I last upgraded. Or maybe I just forgot to check it. I have only 1 IoT device. It's on a guest network and is not particularly important. Maybe I won't worry about the guest networks until I switch to the new router.

... When you do the final router swap, you can clone the external MAC of the router you're replacing and you _should_ keep the same external IP. In case that's important to you, I've not bothered in the past, after all that's why I'm using DDNS in the first place

Same here. I wouldn't need DDNS if I needed the external IP address to stay constant.

 

[Patrick9876]

GL.iNet routers have very user-friendly interface. Perhaps easier than setting up an ASUS router. Just read the manual and you're good.

Good thing I'm going to have both the old and new routers running at the same time. Except for a rudimentary "Quick Start" guide, it looks like most of the manual is online. Tricky if you need the router correctly configured in order to access the manual that tells you how to correctly configure the router.

 

[Patrick9876]

More questions before launch into this. My LAN on my old ASUS router is 192.168.50.0/24. The LAN on my new GL.inet router will be 192.168.8.0/24. I'd like to have communication between the two. Ideally I would like devices on the old LAN to communicate with devices on the new LAN.

15 years ago I was paid to know how to do this - setting up OSPF to build paths between routers - but that was in an enterprise environment. I've forgotten all of that, and I'm pretty sure it does not apply to these home routers anyway. Is there a way to define a port on one of these routers to be in the other router's subnet?

At the very least, I would like my"main" PC on the old subnet to reach 192.168.8.1. I can add a 2nd NIC - a USB Ethernet adapter - to the PC and connect it to the new router but I'd rather have more connectivity than that.

 

[Tech9]

You are overcomplicating things. Your new router needs literally minutes for setting up the basics and you can continue with your configuration from there. DHCP reservations, DDNS service, VPN server/client, etc. don't need reboot, you can do it live. If you insist on this complication with two routers and you want access to the second router from the first - disable the firewall temporarily on the second router. Your client devices may prevent access to different subnet though and you have to deal with this as well.

 

[Patrick9876]

I think I actually do want/need the complication because there a couple of things that are going to take a while for me to configure before I go live.

The first is adding a couple CNAME records to the router's DNS config. This may be easier than I anticipate, but I expect I'm going to have to use the OpenWRT LuCI interface ... which is a complete unknown to me. (And I want to futz around with LuCI just to see what's there. There could be a reset or two before I'm done playing.)

The 2nd, and more difficult task is getting the router to use the FreeDNS DDNS service. This is one of the few DNS services that isn't listed in the DDNS services supported by OpenWRT. The documentation provided by FreeDNS is very old and, according to things on the web, inaccurate. I expect there's going to be a lot of trial-and-error (with emphasis on error) nefore I get this to work. While I don't need this DDNS support as soon as I go live with the router, I expect needing to reboot (and possibly reset) the router to get out blunders I make.

I could, of course, change to one of the supported DDNS services (or even the default GL.iNet DDNS service), but I don't remember how many places I need to change that. I never expected needing to change. I'd rather keep using FreeDNS.

All in all, I expect the configuration process to take days rather than minutes

 

[Patrick9876]

Warning: this is an overly long, and mostly useless posting about my process of getting a GL-iNet MT6000 up and running to replace my perfectly usable ASUS AX86U running Merlin.

Well, this has been an interesting journey. I was right that the configuration process would take days rather than minutes (although getting the initial basic setup did take just minutes).

The documentation in not always thorough and accurate. and definition screens are not all self-explanatory. For instance, setting custom IPv6 DNS server addresses prevents the router from performing local name resolution - all name resolution requests are router to the specified name server(s) so all requests to resolve names of devices on the LAN fail. I don't know if that's a bug or something I set wrong, but it happened two times I tried it.

I was pleased to discover that the FreedDNS DDNS support is now as built into OpenWRT as any of the other (seemingly hundreds) DDNS services. But only GL-iNet's own service is available via the GL-iNet GUI. All others have to be installed through OpenWRT commands (via SSH, etc.) or with the LuCI GUI. LuCI certainly simplifies the process, but it's still a many step process, and the OpenWRT doc is a bit too general to help much. (And the FreeDNS doc is absolutely useless.) Luckily, someone who struggled through the process documented it and posted it on the web.

I found some oddities in the Clients display (like the IPv4 addresses not showing up for one of my NASs). I asked about it on the GL-iNet forum and within a day had the development team poking around on my router - running traces, etc. And two days later had a patch to try. I was impressed.

But my whole reason for switching from ASUS/Merlin to the GL-iNet router was that I wanted a router where defining DNS CNAME records was in the native software rather than via 3rd party firmware. Well, this was also a bit of a rocky jouney. I never did get the CNAME processing to work consistantly, but resorted to setting DHCP static leases and multiple Host names - one host name for each name I wanted mapped to a real device name. Simple ... almost. The real device - a NAS - has an invalid name as far as the LuCI "Host" processes is concerned. The name contains an underscore. (Underscore actually is invalid in a host name but just about everything in the world accepts it ... including the LuCI static lease definitions.) That "lack of support" was just overly picky validation of input fields. Editing the resulting configuration file was the recommended solution.

Editing files on Linux. On the AX86U I used vi to create dnsmasq.conf.add, but that was just putting 1 record in an empty file. Screw-ups didn't cost much. Editing /etc/config/dhcp (with dozens of records) on the new router? My vi knowledge (non-existant) was not up to the challenge. However, being a Windows user, and having used WinSCP as an FTP client for over 20 years I was going to coy the file to my PC when I saw "Can act as a remote text editor". Wow! It showed a directory list, and I double-clicked the dhcp file without even thinking. Up came something that looked just like Window's Notepad. I added the Host definitoin I wanted, clicked Save, rebooted the router, and had the definitions I wanted. And I think I could have just entered a command to restart dnsmasq instead of rebooting. (I'm not sure that would have automatically preprocessed /etc/config/dhcp.)

So what did I learn from this?

• The GL-iNet GUI seems pretty good for general home use, but neither the coding nor the doc seems industrial strength. They've done a pretty good job of adding a user-friendly GUI on top of OpenWRT, but I resorted to using the OpenWRT GUI LuCI many times.
  
  
• The developers of the GUI (however many they are) are not Eric Sauvageau. Merlin is much more professional feeling. Of course, adding a GUI on top of OpenWRT is much different than adding function to ASUSWRT. And there was no need sophistication when users switch to LuCI for more complicated stuff ... or SSH into the non-proprietory OpenWRT. (And brick the router with a finger-check.)
  
• The support team is very easy to work with and is very informative. I just hope I don't continue to need them.
  
• So far the device seems stable and can easily handle my modest traffic needs. How easily it handles my configuration needs is still being determined.

 

[Tech9]

mostly useless posting about my process

No, pretty useful for someone else with GL-MT6000 or with intentions to purchase one. Thanks for sharing!

 

[Patrick9876]

I should probably add that anyone familiar and comfortable with OpenWRT can run the OpenWRT firmware natively on on the MT6000. The GL-iNet firmware is just OpemWRT firmware with a set of plugins providing the GL-iNet GUI. The GUI presents a user-friendly interface for the router, but provides little or no added function. I am not familiar and comfortable with OpenWrt but used the OpenWRT LuCI GUI for part of the configuration process. I assume I could have used it for the whole process.

An advantage of using the GL-iNet firmware is that you can use GL-iNet support. They, of course, cannot change the base OpenWRT code (any more than Eric can change the base ASUS code) but they can provide diagnosis that can point to either GL-iNet or OpenWRT problems. (And, of course, can eventually provide fixes for GL-iNet bugs.)

One very important thing to note. During debugging of problems Gl-iNet support may ask to use GoodGloud - a remote access function. It is trivial to enable the function and fairly straightforward to allow their access to the router (although the doc could be a bit more clear). It is not intuitive how to disable the function, but this is documented on the web. I consider this a security / privacy issue. I left this access enabled for several days after they were done diagnosing a problem.

And a somewhat irritating issue. After one remote access the support team left the GUI language set to Chinese. (That provides a hint as to where the support team is.) Changing it back to English was trivial ... once I found the correct icon to click. It's once of the two with no fly-over help (which would have been in Chinese anyway).