Lost GUI over OpenVPN in 386.1_0

[dardar]

I told my sad story about losing access to a remote RT-AC86U during an update from 384.19 here: https://www.snbforums.com/threads/asuswrt-merlin-386-1-is-now-available.69783/post-661970

I had a friend stop by the house today, and she did a hard reset of the router (WPS hold during power-on--then reboot). I walked her through the initial settings over the phone and had her turn on DDNS and activate remote access over the WAN. I was able to log on to the router remotely, and used the time I was connected to start up the OpenVPN server, connect back to the VPN from a local client, and turn off remote access from WAN.

I was surprised that the system showed it was still on Merlin firmware (I thought it would revert to factory firmware during the hard reset), but that simplified restoring the settings. I probably should have immediately upgraded the firmware to 386.1_2, but instead I noodled around with other configurations. Unfortunately, after enabling and configuring a Guest Network, my access to the GUI was lost, and I am now back where I was before doing the reset (i.e., intermittent VPN connections and brief access to the remote login GUI, but no stable connection).

This router is 2000 miles away, and I don't have another computer-savvy friend available to go back and reset it again. Any suggestions for restoring access? I have spent the entire day learning about iptables, in the hope that I could potentially temporarily regain access through the command line over ssh, and reconfigure the firewall to recover access to the router through WAN without VPN. That doesn't seem very easy. Given how quickly a new version of the firmware was released, I assume the was some bugginess in the intermediate versions, but I have not followed the developers' thread to see what has been happening there or why my configuration of a guest network would completely bork my system. I will not be able to travel to this location for several months, and I am REALLY depressed at how much time I have wasted trying to get this to work.

Any suggestions, or should I just stop trying....

 

[L&LD]

I'm not sure if you restored a saved backup config file. If you did, you effectively nulled the reset your friend did for you.

Doing a full reset to factory defaults doesn't bring back the firmware you originally bought the router with (or the stock Asus firmware, for that matter). What it does is allow the router to use the defaults the installed firmware expects.

Can't the same friend simply reboot the router for you? That may be all it needs for you to have access again.

There is nothing wrong with the stability of the initial 386.1_0 release firmware. Many customers are using this today since I installed it for them. The routers I have upgraded to 386.1_2 are just as stable too.

As you don't specify what settings, features, and options you enable/change on the router, maybe the link below can be of some help to get the router to a good/known state (once you have control over it again).

Best Practice Update/Setup Router/AiMesh Node(s) 2021


Btw, two thousand miles isn't that far. Road trip?

 

[dardar]

@L&LD Thanks so much for your reply. In view of comments I have read here, I did NOT restore from my backed up config file after the reset. I have the identical router locally, so once I had WAN access to the remote router, I opened side-by-side browser windows and used the settings pages from my local router to fill out the corresponding configuration pages on the remote one. I immediately got the remote OpenVPN server started, exported a new OVPN client configuration file, connected with my local VPN client, and then turned off the WAN access. I lost my connection to the remote router after hitting the "apply" button as I was adding a guest network to the remote router. Not sure if the addition of the guest network was the cause of the problem or if it was just a coincidence that something else was going on in the background with the router to cause the connection to break at that point. (By the way, although I called this a "lost GUI" problem, it may really be a VPN server problem.)

I had read your best practices previously, but given that I have two identical devices with almost identical setups, I wasn't too concerned about losing specific settings. I don't have any AI Mesh devices, so my firmware upgrades have typically been pretty routine and reliable in the past. The mistake I may have made updating to 386.1 with this router was not rebooting it prior to the update. I think the router had been up for over 100 days at that point, and I wonder if there may have been enough memory leakage during that time to have caused problems with the update. What do you think?

Still, even if that had caused the original problem, I don't see how it could explain why it happened again yesterday after the reset, since the device had been rebooted multiple times in the interim. After the original episode, I had a maintenance person stop by the house and reboot the router. That didn't change anything, although I don't think he unplugged it (or even necessarily waited very long between pushing the power button off and on). Unless you think a longer wait with the power off would really make a difference, I am not optimistic that a simple reboot will fix the problem this time either.

As I mentioned in my original post, there is a Raspberry pi on my remote network that is set up to VPN back into my local OpenVPN server, and that device continues to connect, albeit less reliably than when the remote router was working properly. I also have a WiFi thermostat on the remote network that continues to phone home to the internet, so I know the remote router was wireless clients and is at least somewhat functional. Given that I did my initial setup after yesterday's reset by enabling access from the WAN, I wonder if I might be able to tweak the firewall on the remote router from an ssh command line in order to get access again without the VPN. For what it's worth, I can occasionally get an OpenVPN client to connect to the router and can gain brief scp and ssh access, so I might be able to send an iptables command or upload a script file. Given how unstable the VPN connection is, I think this may be less of a GUI problem and more of a VPN problem. Any other suggestion for troubleshooting the difference?

Your road-trip idea is appealing (and it might even be faster than me fiddling around remotely for the next week ), but it's not in the cards at the moment. Someone will be at the house again next week, so I may try to walk through another reset with her, but it is painful trying to explain to a non-technical person how this is done, especially if the system borks again immediately after they leave the house....

Thanks again for your help--really nice to be able to bounce ideas off an expert!

 

[L&LD]

Are you using the same LAN IP on both routers? Don't.

What other settings are you duplicating? Unnecessarily and maybe even detrimental to your goals?

 

[dardar]

I am using 192.168.25.1 for my local router with 192.168.26.0/255.255.255.0 as the VPN subnet, and I am using 192.168.50.1 for my remote router with 192.168.51.0/255.255.255.0 as the VPN subnet.
Is that okay?

These two routers are serving pretty symmetric purposes, so I think the duplicated settings are generally appropriate, especially since they are set up on different subnets (and I am even using different SSIDs for the wireless networks). With the previous firmware, I could basically be anywhere in the world and VPN in to either router equivalently with the corresponding VPN client configuration file.

The error message I currently see on my local OpenVPN client when the remote router disconnects is an inactivity timeout:
2021-02-20 13:33:07 [RT-AC86U] Inactivity timeout (--ping-restart), restarting
2021-02-20 13:33:07 SIGUSR1[soft,ping-restart] received, process restarting

My VPN client configuration includes: keepalive 15 60
which I think is probably default, since I don't a configuration for that even on the advanced settings page for the VPN server.

For what it's worth, the remote Raspberry pi that is connected back to my local router's VPN server seems to be connected for about 15-20 seconds and then disconnected for 40-50 seconds. I have been pinging it (at 192.168.26.2) from a local Ubuntu box, and that pattern is very consistent. I can also log in to the Raspberry pi with putty and ping the remote router (192.168.50.1) from there.

I know that OpenVPN 2.5 had a few changes, but I don't know if there was anything that could cause this behavior.

 

[dardar]

@L&LD I discovered today that the default IP address for these routers after a hard factory reset is actually 192.168.50.1, which is what I coincidentally chose to use for my remote router configuration. Could that be a problem? It wasn't an issue in 384.19.

The more I think about this, the more I feel the problem is with the firewall on my remote router. I see that there is a "fw.sh" script in the openvpn configuration directory that has iptables commands to allow incoming VPN connections when the OpenVPN server is started on the router. Is there something similar that runs when a guest network is enabled? If so, that may have caused the VPN to disconnect right after I tried to enable a guest network on the remote router. Is there way to disable a guest network from the command line?

Thanks.

 

[L&LD]

As long as the IP range is different for each network, it shouldn't be a problem.

Search for the cli command to disable the Guest network.

Are you able to access the remote router with the VPN disabled on your local router?

 

[dardar]

Thanks @L&LD. I don't see a difference in accessing the remote router when I turn off the VPN server on my local router, but the remote router is probably in an unstable condition at this point, so I wouldn't draw any conclusions from that.

I discovered yesterday that my local router is also put into an unstable state when I enable the first 2.4 GHz guest network. I had to do a hard factory reset and reload my saved configuration in order to recover function. I repeated the process again this morning--when I didn't have family members screaming at me about the network being down--so I know that the behavior wasn't a fluke. The second and third guest networks can be enabled and disabled without a problem.

I also found the big long thread here about guest networks not working with Chromecast in 386, so I have a better sense that something changed in the background with how guest networks are established (and how they interact with the intranet) in 386. I don't have time to fully understand what's going on behind the scenes, but I am not going to use the first 2.4 GHz and 5 GHz guest networks when I am finally able to have someone reset my router at the remote location again.

It's too bad there isn't some indication in the GUI that the different guest networks might behave differently from one another, depending on whether a user wants them to interact with the intranet. (I'm not using a mesh network, so I don't care about that functionality.) I don't know what I would have done if this forum wasn't available and/or I wasn't compulsive about figuring out what was wrong with my system. After the big long discussion about the Chromecast issue, the developers may want to consider labeling the different guest networks differently. They should also keep in mind from my experience that a VPN server might not play nicely with the first guest networks.

Thanks again.