What's new

RT-AX56U - How to test the VPN Killswitch?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

oxfordshirebiker

New Around Here
Hi folks,

I am hoping this is an easy one for someone to answer. Please excuse the language if I am not techy enough ;-)

I would like to know if there is a way to test the VPN Killswitch? I know that sounds simple, but so far I haven't found a way to do it - below is what I have tried so far:

Here is my configuration:
Asus RT-AX56U running Merlin 386.3_2

I have one device (a laptop) I would like to permanently run through a VPN, but I would like its internet connection to be blocked if the VPN goes down. The laptop is manually assigned IP in DHCP. Have checked to be sure the laptop has the IP it should be assigned - OK. I only have 1 internet interface on the laptop.

OpenVPN Client1 setup as follows:
Automatic start at boot time > YES
Redirect internet traffic through tunnel > VPN DIrector
Killswitch - block routed clients if tunnel goes down

VPN Director setup as follows:
There is only one rule with the following settings:
Interface > OpenVPN1
Enabled > Yes (tick)
Local IP > The laptop IP that I want to run though the VPN

The VPN is working and I have tested traffic through it all OK. I have tested with What Is My IP to be sure I am on the VPN, and all is working great with my IP shown as the VPN provider IP! The VPN director shows it as Connected | VPN Director + Killswitch and I have a Green Tick. All is working on the VPN.

BUT - I haven't been able to test if the kill switch is working? So far I have tried the following:
  • I have tried the 'Stop Client' option in the VPN director - this closes the VPN connection, but the laptop stays online and starts using the main WAN (running What Is My IP - it shows my WAN IP address, not my VPN IP) - so I assume by using the 'Stop Client' the system knows I have turned it off manually and therefore routes my traffic on the main WAN - so it doesn't simulate the VPN dropping or trigger the kill switch
  • I have also tried changing the 'Service State' of the VPN to OFF, but once again it reverted my laptop onto the main WAN and did not 'kill' the connection. Once again I assume that is because I manually turned off the VPN Client, the system doesn't treat it as a trigger for the kill switch

SO - is there a way to test the kill switch? As the VPN is working great and the VPN director is only applying it to the laptop which again is great, but I would like to test the kill switch to be sure it works, just in case the VPN does ever drop.

If anyone can shed some light on this, it would be great to hear.

Cheers

Rob
 
The kill switch only works for abnormal termination of the OpenVPN client, which does NOT include YOU turning it OFF. To force a failure, you can simply kill the OpenVPN process for that client by locating it in the process table via ssh.

Code:
kill $(ps | grep [v]pnclient1 | awk '{print $1}')

At that point, you'll find the default route in the relevant routing table for that OpenVPN client has been blocked w/ a 'prohibit'.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
186.233.184.187 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
192.168.101.0/24 dev br1  proto kernel  scope link  src 192.168.101.1
192.168.102.0/24 dev br2  proto kernel  scope link  src 192.168.102.1
192.168.3.0/24 dev wl0.2  proto kernel  scope link  src 192.168.3.1
192.168.50.0/24 via 10.8.0.2 dev tun21
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.63.0/24 dev vlan2  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2  metric 1
127.0.0.0/8 dev lo  scope link
prohibit default

That's what actually prevents further internet access to those bound to that OpenVPN client.
 
Last edited:
Thanks eibgrad for the very swift and informative reply.

I will give the test a go with the ssh, thank you so much for posting the commands as I would be lost without them!

I won’t be able to test till tomorrow, but will let you know how I get on.

Cheers
 
Hi @eibgrad and others.

Thanks for the assistance of testing the switch, by killing the VPN process via ssh. It worked great!

I know this is cheeky, but are you able to send me the ssh command for re-starting the process, after it has been killed? I just restarted the router to get it back up and running for now, but figure there is likely an ssh command that could start the process without a restart after testing.

Many thanks and appreciate any assistance you can provide.

Very impressed with the Merlin firmware!.....and the active community or users & techs with far more knowledge than many of us! .......certainly encouraging me to try out new features and grow my knowledge.

Cheers

Rob
 
I know this is cheeky, but are you able to send me the ssh command for re-starting the process, after it has been killed? I just restarted the router to get it back up and running for now, but figure there is likely an ssh command that could start the process without a restart after testing.

Code:
service restart_vpnclient1
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top