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.