AC86U Merlin VPN Kill Switch

[ChrisM]

ASUS RT-AC86U with Asuswrt-Merlin - Current 382.1_2

But have tested this with (382.1_2) & (382.2_beta3) & (384.3_beta3)
The results are the same for all of them

Bug or Feature ??
(it depends on how high the fence is and on what side your standing on)

Open box, install, upgrade Asus firmware, factory reset
Install firmware Merlin, factory reset
Configure WAN then LAN DHCP followed by VPN Clients and External Storage - now at this point - testing


*** ->> The Problem I am having is this <<- ***

VPN Client set Exclusive
Fixed IP mapped to PC in DHCP
Policy rule to route PC to VPN
Kill switch active
Start with WAN set to Off

Testing done with only 1 Client installed
(more makes results confusing )

Once the VPN Client has been active ON and the PC correctly protected internet used etc when the Client is toggled OFF to return the router to normal the Kill switch Policy rule filter is NOT reset - stopping the PC from WAN access. (could be an internal table not flushed when all Client Off)

Its a fault because there are no longer any VPN clients active
All have been manually switched Off
The router should now Allow the once VPN protected PC back on to the WAN and It Does Not

Various ways I have found to let the PC back onto the WAN are
a.) Toggle the internet connection On/Off via the Internet Status setting page. (interrupts all other connected users in the process of course)
b.) Change the Kill Switch setting to NO and then Apply update to Client works even though the VPN Client is in the Off state. (quickest)

Strange but I also found that after you have connected just once to the VPN and then manually switched Off the Client, you can then toggle the Kill switch to the Client On or Off applying update after each time to see the effect of none and then allowed WAN access of the PC in the policy rule

I understand its purpose is to halt the access to the WAN in the event of disconnection of the VPN but fail to see why manually switching Off the client function does not reset clear it.
(proviso no other Clients are still active of course or should it clear that Clients table only)

Testing of this with the Kill Switch Not active from the start of test DOES Allow the PC to connect back to the WAN after the VPN Client is manually switched Off, as the Kill switch has not been active in the first place. But again if the Kill Switch is then toggled to the On and the apply update done
the PC is again blocked even though the Client still remains in the Off state.
(you must have been to the internet and used the WAN of course)

This only presents its self as an issue when the Kill Switch is Active and the
VPN Client is switched OFF manually after routing the PC through the VPN,
Or if the Kill Switch is toggled On and the settings updated post VPN connection. (with the Client still in the Off state)

Has anyone else had this happen to them?
Is this Feature known of already?

Can this be looked at please its confusing.

*** ->> END <<- ***

This is my first taste of ASUS routers but heard great reviews of them in the past. I was a Netgear man for may years before finding a likening for CISCO kit. Had a X2500 switched on for two years straight without faulting.

The ASUS has lots of good features and compares well if not better with other routers and as hardware improves the leap in performance is very gratifying to have.

My thanks go out to RMerlin for his hard work in supporting all this complex
Router Software a very LARGE Thank you Sir. (long may you continue)
An amazing Job for one person to maintain.

Ending Note: -

I will End this with the unit is working correctly and functioning well with
DNS hidden in either normal internet using OpenDNS or VPN with NordDNS (ISP - Virgin Media. VPN - NordVPN)

Setting up of hidden DSN was hard work trial and error until final working point found. (just had to keep reading the net)

Had trouble getting external NTFS storage to work until I found if you
FORMAT the drive whilst connected to Asus unit then everything Ok
(file name error msg gone and download manager now finding drive)

Router did get its self in a right mess at one stage and start saying connected to VPN on VPN status page with all clients switched off. A factory reset and rebuild was needed but this cured the issue and it has not happened since (touch wood)

IMPORTANT - Note to NordVPN users -
the pre config ovpn files supplied by Nord for setting up VPN Clients is wrong (reported)
ending script is in error and the script at the bottom of the tutorial should be substituted see here -
https://nordvpn.com/tutorials/asustwrt-merlin/openvpn/
#
remote-cert-tls server
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping-timer-rem
reneg-sec 0
# log /tmp/vpn.log

 

[Martineau]

Its a fault because there are no longer any VPN clients active
All have been manually switched Off
The router should now Allow the once VPN protected PC back on to the WAN and It Does Not

I understand its purpose is to halt the access to the WAN in the event of disconnection of the VPN but fail to see why manually switching Off the client function does not reset clear it.

Working as designed IMHO

Scenario:
'Start with WAN=NO'
'Block routed clients if tunnel goes down=YES'

If you reboot then ALL LAN devices that have been defined in the VPN Client GUI should be BLOCKED until a successful VPN connection is established (either via a cron job or manually via the GUI.)

Now suppose (for whatever reason) you have designated that a specific device must ONLY pass it's private (possibly dubious?) traffic via the obfuscated VPN tunnel.

e.g. Suppose I have to access my bank account to make a large transfer. I need to securely access say the HSBC online web portal via port 80 and I wish to ensure the transaction cannot be seen by my ISP etc., so I always use a specific laptop and its mandatory VPN tunnel.

Now wouldn't it be rather silly to allow the laptop to suddenly have unencrypted access to the banking web site via the WAN because I have previously manually stopped the VPN but stupidly forgot to turn the VPN back on?

If you honestly need to automatically remove the VPN Kill-switch, then you may be able to exploit the openvpn-event vpnclientX-down script to explicitly remove the 'prohibit default' route etc. from the appropriate VPN client's Selective Routing table in a more intelligent way?

But I suspect the most reliable way would be to monitor Syslog (search forum for my VPN_SyslogMonitor.sh script)
and ONLY remove the VPN client's Kill-switch when it matches the following trigger:

kern.notice rc_service: waitting "stop_vpnclientX" via httpd ...

assuming of course that the above message only appears as a result of a human manually changing the VPN Client status to 'DOWN' via the GUI.

NOTE: At the next reboot the Kill-switch will be reinstated.

 

[ChrisM]

Working as designed IMHO

Scenario:
'Start with WAN=NO'
'Block routed clients if tunnel goes down=YES'

If you reboot then ALL LAN devices that have been defined in the VPN Client GUI should be BLOCKED until a successful VPN connection is established (either via a cron job or manually via the GUI.)

Under the above scenario defined ALL traffic would bypass any policy processing and be allowed access to the internet after reboot.

As the - Start with WAN = No. a reboot just opens up the router to work with No Vpn and No policy processing, which is correct.

Now wouldn't it be rather silly to allow the laptop to suddenly have unencrypted access to the banking web site via the WAN because I have previously manually stopped the VPN but stupidly forgot to turn the VPN back on?

If you turned it Off, then it should be Off, regardless of the reason.
Stupidity would be to do any banking without testing that the Vpn was up and working correctly.
Assuming anything in the World of IT is at your peril .

I did just that and stupidly assumed that when I turned it Off it was Off and no residual policy processing was in place which wasted many hours of testing.

I suspect the most reliable way would be to monitor Syslog (search forum for my VPN_SyslogMonitor.sh script)

A lot of users don't have a clue about SSH usage, coding, scripts or where to begin to even look into the Syslog.

For the ordinary punter in the street it is enough to know that
On is On and Off is Off
(With no assumptions being made or inferred at any point)

I suppose this is why the router with Merlin is so liked and popular as there are so many different ways it can be configured without needing any specialist scripting at all.

Taking your stand point of being safe and not wanting anything to get out I fully understand - Start with Wan = Yes and BLOCK the world and his dog if I have not said otherwise
(that would be Client = Strict & Policy = Strict then )

 

[Martineau]

If you turned it Off, then it should be Off, regardless of the reason.

I have previously (3 years ago) stated that the wording of the GUI option is misleading and should actually be

'Block routed clients if tunnel is DOWN=YES/NO'

as clearly that is what the firmware enforces. Simply changing the wording would remove all ambiguity as it wouldn't matter how the VPN Client state changed to DOWN or indeed if it never came UP in the first place.

Since this has always been the case in the firmware, I'm sure it will remain that way, and the banking illustration was an unrealistic hypothetical case to explain my point as to why I believe @RMerlin has persisted with his original design implementation.

NOTE: In the case of my hypothetic banking scenario, you could simply add all of the appropriate online banking IP addresses/subnets to the VPN Client GUI so all banking transaction traffic from the designated device must only be via the ACTIVE VPN tunnel (and BLOCKED if it isn't), whilst allowing the non-banking traffic outbound from the device to be always via the WAN.

 

[john9527]

Just as an FYI....I implemented the choice of behaviors in my fork....

 

[Martineau]

Just as an FYI....I implemented the choice of behaviors in my fork....
View attachment 12002

Yes, indeed there are some very useful bespoke features that never quite seem to make it to the @RMerlin firmware but I guess that's why you retain your solid loyal client base!

P.S. You may be getting a new subscriber!

 

[john9527]

but I guess that's why you retain your solid loyal client base!

Thanks....but it is a shrinking client base. Especially with the intro of AIMesh and the AC86.

 

[RMerlin]

Yes, indeed there are some very useful bespoke features that never quite seem to make it to the @RMerlin firmware but I guess that's why you retain your solid loyal client base!

It's easier to add features when you don't need to merge major GPL releases every 2-3 months, requiring you to revise (and possibly re-implement) previously added features. My customized DHCP page for instance had to be re-implemented twice already because of upstream changes from newer GPL. And 382 required me to basically rewrite a large portion of the OpenVPN implementation. I think it took me close to a month to get OpenVPN back to where it was before (and there were still some issues that popped up in the following weeks).

And there's also the matter of available time. Things on my TODO list often end up spending 6-12 months there before I can find the time to look into them. The extended WPS button capabilities for instance - took me two years before I finally found the time to look into it, and ultimately shelve it indenfinitely because the wanduck/watchdog code has grown exponentially complex since the 3.0.0.3 days when I first implemented it...

Since work began on 382 last September, I haven't had time to implement a single new feature - all the development time was spent just trying to migrate devices, fix issues, and keep things together. 384.4 might be the first break I get since last October.

 

[RMerlin]

Thanks....but it is a shrinking client base. Especially with the intro of AIMesh and the AC86.

You should get a few refugees soon once I push out 380.70 as the final 380.xx release from me.

 

[RMerlin]

BTW' revisiting the OpenVPN kill-switch behaviour is something I added to my TODO list back in October...

 

[ChrisM]

BTW' revisiting the OpenVPN kill-switch behaviour is something I added to my TODO list back in October...

Great its a known Feature and on the TODO list and known about.
My brother lives in Canada I will get him to send you a ROUNDTOIT they don't actually help in any way but the humor factor is always nice.

One more bash at explaining the situation to @Martineau and I will give up and get back to enjoying your new release.

I must say going back to the original Asus software is a shock.
Its so sparse by comparison, give me your version any day.
(with or without features its so much better)

 

[RMerlin]

Great its a known Feature and on the TODO list and known about.

I didn't say I was going to change the behaviour to what you expect, only that I would revise how it's currently implemented.

 

[ChrisM]

I have previously (3 years ago) stated that the wording of the GUI option is misleading and should actually be

'Block routed clients if tunnel is DOWN=YES/NO'

as clearly that is what the firmware enforces. Simply changing the wording would remove all ambiguity as it wouldn't matter how the VPN Client state changed to DOWN or indeed if it never came UP in the first place.

Try these then with only 2 vpn client defined.
1.)
vpn set exclusive
start on wan set to no
policy block set to yes
Reboot the router
You will see no blocking
This does not mirror what you have said
The vpn client and the policy block are intrinsicaly linked to one another or should be
2.)
vpn set exclusive
start on wan set to yes on client 1
policy block set to no
Reboot the router
Visit two/three different internet sites
Switch vpn Client 1 off so zero vpn clients active
Now go to other Client 2 and whilst still set off
change policy block to yes and apply update etc


You will now find that the block has been switched on even though both the actual vpn clients remains off and were off at the time of change also that the vpn client 2 where the block was switch on has nothing to do with the original vpn client 1 that had gone through the tunnel in the first place

The block is part of the vpn client options and should be unique to the respective vpn client it is action.

If there are zero vpn clients active there should be zero blocks active. Regardless of previous usage. A reboot proves this in test 1 above.

If vpn client 1 was previously active with block off and I adjust the settings in vpn client 2 to include a block it should not then be active after updating the settings in vpn client 2 in vpn client 1

Like I said before if its off it should be off regardless of the vpn clients current or past activity

Since this has always been the case in the firmware, I'm sure it will remain that way

It is a known about apparently and on the TODO list as of last October (see above Rmerlin post)

 

[Martineau]

It is a known about apparently and on the TODO list as of last October (see above Rmerlin post)

You mean this?

 

[ChrisM]

I didn't say I was going to change the behaviour to what you expect, only that I would revise how it's currently implemented.

I fully understand - but the fact that you do know of there being an issue is all i wanted too make you aware of. Whatever is done it will get your normal buckets of logic thrown over it and whatever the outcome it will be good for all. At least I now know of ways to reset it without having to reboot every 5 mins and this helps me as a get round during testing.