Loss of access to user interface after application of VPN rule and Killswitch (3004.388.8)

[Unetwork]

Hi,
I updated the latest firmware without reading the changelog (sorry) and found myself without access to local web interface (I've read on other subjects that other people have had the same problem).
I had to perform a WPS reset to get the router working again. I then realized that it was due to this rule.
If I put it back and apply it, I lose access to the router again, so I have to perform a reset, which is frustrating :

PS : another member has helped me in the meantime (many thanks to him)
I now need to set up these two rules so as not to lose access to the router :

ROUTER IP (192.168.X.X) => INTERFACE WAN
IP OF THE WHOLE NETWORK (192.168.X.0/24) => INTERFACE OVPN1

When I apply the killswitch, I no longer lose local access to the router.
I also have to remove the killswitch to get back to my normal connection without the VPN. A lot of strange things in this new version.
It was much simpler with 388.7. I hope a clarification will be made in the next update.
I think a lot of people are going to be fooled...

Thanks in any case to Merlin for his work.

 

[eibgrad]

As I mentioned in the release thread ...

Release - Asuswrt-Merlin 3004.388.8_2 is now available

Dirty upgrade from 3004.388.7 to 3004.388.8 on RT-AX88U with no issues.

www.snbforums.com

This shouldn't be an issue if you're accessing the GUI from a LAN device to the LAN ip of the router. But it *will* if you reference the router's WAN ip (or domain name) because you're doing (or enabled) remote access. Fact is, it's *always* been this way (i.e., the fact there's a DNAT from the WAN ip to the LAN ip which makes routing the entire local network (e.g., 192.168.1.0/24) through the OpenVPN client problematic w/o an exception on that same local IP network). So it's not obvious to me why things have necessarily changed w/ the latest release.

 

[Unetwork]

As I mentioned in the release thread ...

Release - Asuswrt-Merlin 3004.388.8_2 is now available

Dirty upgrade from 3004.388.7 to 3004.388.8 on RT-AX88U with no issues.

www.snbforums.com

This shouldn't be an issue if you're accessing the GUI from a LAN device to the LAN ip of the router. But it *will* if you reference the router's WAN ip (or domain name) because you're doing (or enabled) remote access. Fact is, it's *always* been this way (i.e., the fact there's a DNAT from the WAN ip to the LAN ip which makes routing the entire local network (e.g., 192.168.1.0/24) through the OpenVPN client problematic w/o an exception on that same local IP network). So it's not obvious to me why things have necessarily changed w/ the latest release.

thank you for this information.

Nevertheless, I find this new function more complicated to understand. Especially as if you set a 192.168.X.0/24 rule by mistake and activate Killswitch, you lose local access to the router and have to reconfigure all the parameters after a reset.

I never had this problem with previous versions of Merlin with the VPN-only rule (image in my first post) and when I activated the killswitch. Now I have to do both rules (WAN and OVPN1) otherwise I short-circuit. It's a strange way of working.

I hope this will all be simplified in the next version and there will be a safeguard instead of corrupting the router.

PS : I still see on other posts that there are VPN routing errors, so it's not clear to others either on this new version.

 

[eibgrad]

There have been a couple of changes in the new release that are proving problematic. The kill switch change, and the change to the OpenVPN client ip rules as described in the following thread.

vpn problems in asuswrt merlin 3004.388.8

Hi, I have the following setup up and running and it is working like a charm OpnSense RT-AX58U 3004.388.7 (asuswrt merlin) OpnSense (iPhone/Mac) I can connect from the OpenVPN Roadwarrior to like everything. Today I tried to replicate that for a friend and it didn't work. OpnSense...

www.snbforums.com

I suspect the combination of these two changes is leading to unexpected complications such as yours. But it's a bit too early to know whether we need to adjust how we're doing things NOW to accommodate those changes, OR, whether those changes need to be undone or modified in the next release. It's NOT even clear to me why these specific changes were made. Even Merlin himself only had a partial memory of the justification.

So we need to be patient over the next few days and see how things flush out as more ppl will inevitably begin to complain.

 

[Unetwork]

Thank you for taking the time to respond to me again. Indeed, it is problematic.
Many people are probably on holiday but when they return, if they update their router it will be impacted.
I hope all this will be fixed in the next version.
We will follow this more closely.

 

[Unetwork]

@eibgrad
Hello,
I've just seen that the new version 388_2 has been released. Can I do this rule again with the Killswitch constantly on as before ?

 

[eibgrad]

@eibgrad
Hello,
I've just seen that the new version 388_2 has been released. Can I do this rule again with the Killswitch constantly on as before ?
View attachment 60680
View attachment 60681
Or will I lose control of the web interface again ?

IIRC, both Merlin and I came to the conclusion that it's best to permanently bind the router's LAN ip to the WAN w/ the VPN Director, just in case.

 

[Unetwork]

Thanks for the quick feedback.
So I need to implement these two rules to not have any worries ?
(So I have to apply these two rules so as not to have any problems? (also leave the Killswitch OFF when it's not in use ? whereas before you could leave it ON even under normal circumstances)
Is that right ?

 

[eibgrad]

Well, to be more precise, we came to that conclusion about binding the router's LAN ip to the WAN w/ the VPN Director *because* of the changes to the kill switch behavior.

Our concern is when users bind the entire private IP network to the VPN (e.g., 192.168.50.0/24) (which implicitly includes the router) w/ the VPN Director, and fail to disable the kill switch whenever the OpenVPN client is disabled/OFF. It has *always* been problematic having the router's LAN ip bound to the VPN should you attempt to access the GUI via the WAN ip (or DDNS domain name). That hasn't changed. But prior to this release, disabling the OpenVPN client also disabled the kill switch, and so everything returned to normal.

But w/ this new release, the kill switch itself is now persistent, irrespective of the state of the OpenVPN client. And in terms of its effect, it's as if the OpenVPN client is once again active, except no internet access is possible; everything is just blocked.

So at that point you have two choices; either remember to disable the kill switch each time you disable or turn OFF the OpenVPN client, OR, prevent the router from ever participating in the VPN in the first place w/ that rule. Seems to me the latter is the simpler and less error-prone solution. The former leaves you a possible victim of your own absent-mindedness.

FWIW, Merlin has even considered the possibility of adding the rule to firmware by default, esp. given the side-effects of these kill switch changes.

 

[Unetwork]

Once again, thank you for taking the time to explain all these changes correctly.
As a precaution, I'm going to add my two rules as shown in the image below.
As I'm often distracted, thanks to these two rules, I won't have to think about disabling the killswitch every time, at the risk of losing control of the web interface.
Thank you for taking the time to clarify these points.

 

[side]

I wish I saw this thread.

Same situation, locked out of interface.

 

[SaBl]

So I just got the AX88U Pro and installed the latest firmware with factory reset. There seems to already be a lot of posts regarding killswitch issues, but I just want to confirm that I understand this issue.

On my AC86U I had openvpn client to a commercial vpn, I wanted to test the same with wireguard with this router. I have a rule like 192.168.50.1/24 to redirect all traffic to the VPN and separate rules for individual devices to bypass the VPN. Everything seemed to work fine. On the VPN Status page, I unchecked the green mark on the vpn client connection to turn it off. The interface immediately stopped working, as well as all ethernet connections and wifi connections. No device was able to connect to the router, reboots did not thing and it did not respond to pings. I had to reset using wps method.

From my understanding, the killswitch now stays on even if you turn off the vpn connection, and if you have a rule to route all devices to that connection, the router itself becomes inaccessible, correct? I thought I read some posts that it only becomes inaccessible over WAN or that internet should still work but that the webui doesn't. In my case the router basically became a brick.

To avoid factory resetting this router again and doing all the settings all over again, I should add an additional rule for the router ip address and set to it WAN. If I want devices to access the internet when disabling the vpn connection, I should also disable the rule to route all clients through the tunnel when turning off the vpn. Did I understand the issue correctly?

Thank you for your help.

 

[ZebMcKayhan]

To avoid factory resetting this router again and doing all the settings all over again, I should add an additional rule for the router ip address and set to it WAN. If I want devices to access the internet when disabling the vpn connection, I should also disable the rule to route all clients through the tunnel when turning off the vpn. Did I understand the issue correctly?

I'm sorry, I don't know if your issue is related to the kill switch. I have not used it myself. It possible though.

But I would like to provide you with an alternative methode wich provides alittle more flexibility and avoids creating overlapping rules.

Head into router gui. LAN -> DHCP Server. Here there is a field "IP Pool Starting Address" this is probably 192.168.50.2 for you.
Change this to 192.168.50.16.

this means no clients will be assigned ip below 16.

Now head into VPN director and create 4 rules (assuming no other rules exists):

Local IP: 192.168.50.128/25
Remote IP: leave blank
comment 128-255
Interface: WGC1

Local IP 192.168.50.64/26
Remote IP: leave blank
comment 64-127
Interface: WGC1

Local IP 192.168.50.32/27
Remote IP: leave blank
comment 32-63
Interface: WGC1

Local IP 192.168.50.16/28
Remote IP: leave blank
comment 16-31
Interface: WGC1

(Don't forget to hit apply on VPN Director page when you are done).

Now, your rules does not include the router as these only include 192.168.50.16 - 192.168.50.255.

If you ever need to exclude some device from vpn:
Head into router gui. LAN -> DHCP Server.Change Enable Manual Assignment to yes if no

then further down in "Manually Assigned IP around the DHCP list" you may already have static assigned clients here. Change all clients that should be excluded from vpn to have ip below 16 (Like 192.168.50.5, 192.168.50.6, 192.168.50.7). If you have other static assigned ip here for vpn make sure they are above 16 if you want them to be over vpn.

 

[Dougj]

Thank's for all the help. I guess I'm factory resetting and hoping my back restores successfully or I rebuild.
D.

 

[SaBl]

Thank you for the write up ZebMcKayhan. In my case I think that set up would complicate things a bit since I have static ip devices below 16 and also because I sometimes need to toggle wan bypass for certain devices back and forth so manually assigning ips back and forth would add extra steps. I'm good with the current set up, I just wanted clarification on the killswitch issue since it seems to be causing havok under different scenarios.