OpenVPN client & killswtich, what am I missing ?

[GSpock]

Hi,
I have 3 clients protected by OpenVPN (VPN Director set to "policy rules" and Killswitch - Block routed clients if tunnel goes down set to "No"). So far so good.
Last week, my VPN Provider had servers failures and my OpenVPN client could not connect anymore ; in this situation I would have expected that my 3 clients would go thru the WAN, but it did not happen. All of them lost complete internet access .... until I manually tried to restart the OpenVPN client ; at that point, I could not reach the server (it was still down) but the clients could go thru the WAN.

So, what am I missing here, I was expecting the clients to fall back automatically to WAN .... ?

Thx,
GS

 

[eibgrad]

The fact you do NOT have the kill switch active does NOT mean you will necessarily have access to the WAN (or more specifically, the default gateway of the WAN). It only guarantees when active that it's NOT accessible.

As long as the OpenVPN client is ON and attempting to (re)connect, it's entirely possible the relevant routing table (e.g., ovpnc1) is still established, along w/ a default route that still points to the prior VPN gateway, even if that gateway isn't currently reachable. Particularly since the OpenVPN client uses the persist-tun and persist-key directives. This prevents the tunnel from being deconstructed during reconnection attempts. The only time things return to "normal" (as in the default gateway of the WAN becomes available again) is when the OpenVPN client finally quits trying to connect.

FWIW, we recently removed these two directives from DD-WRT for several reasons (but not particularly for your concerns). They can cause other side effects, and aren't really necessary (imo) once you have the option of a kill switch.

#7393 (Removal of persist-tun and persist-key from OpenVPN client) – DD-WRT

svn.dd-wrt.com

I suppose you might consider removing them from the Merlin config file using an OpenVPN client postconf script, just to see if it helps.

 

[GSpock]

Thanks. The "directives" you are refering to are not present in my openvpn client config file ....
Is my understanding of the kill switch correct or not then ? ...
GS

 

[eibgrad]

Thanks. The "directives" you are refering to are not present in my openvpn client config file ....
Is my understanding of the kill switch is correct or not then ? ...
GS

That seems odd. They are clearly in my own OpenVPN client config. And I don't see why it would vary. Usually these kinds of directives are just added automatically, as part of the default for any OpenVPN client configuration.

admin@lab-merlin1:/tmp/home/root# cat /tmp/etc/openvpn/client1/config.ovpn | grep persist
persist-key
persist-tun

If there is no kill switch, and there's no persist directives, I would expect the WAN to be available, even if the VPNs failed. After all, that's the point of the kill switch, to make sure that doesn't happen. I'd have to look more closely at exactly how the various data structures looked when this happen to venture even a guess why this is happening.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule

 

[Kingp1n]

That seems odd. They are clearly in my own OpenVPN client config. And I don't see why it would vary. Usually these kinds of directives are just added automatically, as part of the default for any OpenVPN client configuration.

admin@lab-merlin1:/tmp/home/root# cat /tmp/etc/openvpn/client1/config.ovpn | grep persist
persist-key
persist-tun

If there is no kill switch, and there's no persist directives, I would expect the WAN to be available, even if the VPNs failed. After all, that's the point of the kill switch, to make sure that doesn't happen. I'd have to look more closely at exactly how the various data structures looked when this happen to venture even a guess why this is happening.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5

What would be the proper way to remove persist-key and persist-tun?

Update: nvm,...i want here (tmp/etc/openvpn/client1/config.ovpn) and deleted them.

 

[eibgrad]

What would be the proper way to remove persist-key and persist-tun?

If you enable JFFS scripts under Administration->System, and copy/paste the following into an SSH window, it will remove them (of course, it's configured for OpenVPN client #1, adjust as needed).

cat << 'EOF' > /jffs/scripts/openvpnclient1.postconf
#!/bin/sh
. /usr/sbin/helper.sh
pc_delete 'persist-tun' "$1"
pc_delete 'persist-key' "$1"
exit 0
EOF
chmod +x /jffs/scripts/openvpnclient1.postconf

 

[eibgrad]

Update: nvm,...i want here (tmp/etc/openvpn/client1/config.ovpn) and deleted them.

You can't just delete them that way. That won't persist. The next time the OpenVPN client is initialized, it will just put them back. You need to use the script I provided previously.

 

[Kingp1n]

You can't just delete them that way. That won't persist. The next time the OpenVPN client is initialized, it will just put them back. You need to use the script I provided previously.

Would I need something similar to remove this?

reneg-sec 0

 

[eibgrad]

Would I need something similar to remove this?

reneg-sec 0

That directive is NOT normally part of the default OpenVPN client configuration. Setting that to zero (0) disables updating of the session key, which happens every 3600 secs (60 mins) by default. That could only happen if the OpenVPN provider told you to add it, or perhaps they buried it in their .ovpn config file for import purposes (but even then I would expect that to be copied into the custom config field where you can easily remove it).

 

[GSpock]

If you enable JFFS scripts under Administration->System, and copy/paste the following into an SSH window, it will remove them (of course, it's configured for OpenVPN client #1, adjust as needed).

cat << 'EOF' > /jffs/scripts/openvpnclient1.postconf
#!/bin/sh
. /usr/sbin/helper.sh
pc_delete 'persist-tun' "$1"
pc_delete 'persist-key' "$1"
exit 0
EOF
chmod +x /jffs/scripts/openvpnclient1.postconf

Thanks! now, how do I test this is working as expected, in other words how do I simulate a server failure at my provider side ?

 

[eibgrad]

Thanks! now, how do I test this is working as expected, in other words how do I simulate a server failure at my provider side ?

Admittedly, this is a bit tricky to configure.

What I suggest is you configure the OpenVPN client for a single server IP or domain-name. IOW, no additional remote directives. Once the OpenVPN client is established, then block access to that server IP or domain-name using a firewall rule via SSH.

iptables -I OUTPUT -d <server-ip|server-domain-name> -j DROP

Eventually the OpenVPN client will detect the loss of connectivity (be patient) and initiate an inactivity timeout. Once that happens (and you can monitor the syslog for that event), you should be able to still traceroute over the WAN for those clients bound to the VPN. At least until the VPN is reestablished.

To reestablish the VPN, delete the same firewall rule.

iptables -D OUTPUT -d <server-ip|server-domain-name> -j DROP

NOTE: At least in my own case, this was NOT enough to get the VPN running again. I had to force a restart w/ a service command. Not sure why.

service restart_vpnclient1

Now your traceroute from those same LAN clients should be over the VPN again.

 

[GSpock]

Admittedly, this is a bit tricky to configure.

What I suggest is you configure the OpenVPN client for a single server IP or domain-name. IOW, no additional remote directives. Once the OpenVPN client is established, then block access to that server IP or domain-name using a firewall rule via SSH.

iptables -I OUTPUT -d <server-ip|server-domain-name> -j DROP

Eventually the OpenVPN client will detect the loss of connectivity (be patient) and initiate an inactivity timeout. Once that happens (and you can monitor the syslog for that event), you should be able to still traceroute over the WAN for those clients bound to the VPN. At least until the VPN is reestablished.

To reestablish the VPN, delete the same firewall rule.

iptables -D OUTPUT -d <server-ip|server-domain-name> -j DROP

NOTE: At least in my own case, this was NOT enough to get the VPN running again. I had to force a restart w/ a service command. Not sure why.

service restart_vpnclient1

Now your traceroute from those same LAN clients should be over the VPN again.

When testing the above scenario, as soon as I issue the iptable -I statment, my log file becomes full of the following messages:

Dec 16 15:49:50 ovpn-client3[31990]: write UDP: Operation not permitted (code=1)

 

[eibgrad]

When testing the above scenario, as soon as I issue the iptable -I statment, my log file becomes full of the following messages:

Dec 16 15:49:50 ovpn-client3[31990]: write UDP: Operation not permitted (code=1)

That's to be expected. And eventually it should cause an inactivity timeout and try to restart. If that's NOT happening, then perhaps your OpenVPN provider is NOT push'ing a keepalive directive as part of the server's configuration (most do). You may have to add your own to the OpenVPN client in the custom config field.

keepalive 10 60