OpenVPN clearing static routes on VPN teardown

grogling

Hi, I am having a problem where OpenVPN is clearing static routes from the routing table when OpenVPN closes the VPN connection.

I have a simple network setup. No default gateway is setup and only a single route exists towards the address of the VPN server. This is so that no network traffic can flow outside the local lan until the VPN has been established.

Once OpenVPN starts, it adds the appropriate routes to the routing table and everything operates as expected.

When I stop OpenVPN, instead of just removing the routes it has created, it also removes the static route towards the OpenVPN server, thus if OpenVPN is started again, it cannot access the VPN server. A problematic situation.

I am creating the static route in /etc/network/interfaces with a "post-up route add" statement.

client
dev tun
proto udp
remote {remote address} {port}
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass {password file}
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.pem

Traffic

Please see the Forum rules (top of page)

grogling

Which rule in particular have I not followed? I thought I had followed the rules above.

maikcat

please also post logfiles..

Michael.

Traffic

grogling wroteWhich rule in particular have I not followed?

as Michael suggests: your log files .. and how about your server config ... :roll:

In this case it may also help if you post these details:

grogling wroteI am creating the static route in /etc/network/interfaces with a "post-up route add" statement

grogling

Traffic wroteas Michael suggests: your log files .. and how about your server config ... :roll:

I'll happily supply the info asked for, but I will also point out, the rules clearly state "If you are having problems connecting" which I clearly am not. The reason I didn't post the server config is because I have no access to the server which is a commercial VPN service. Is there a way of having the client report any configuration pushed down from the server?

######## /etc/network/interfaces ###################
auto eth0
iface eth0 inet static
        address 192.168.1.19
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.250
        post-up route add -net {vpn server} netmask 255.255.255.255 gw 192.168.1.1



############# Routing table pre-VPN ##########
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.250   0.0.0.0         UG    0      0        0 eth0
{vpn server}    192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

############ Start VPN #########################
 * Starting virtual private network daemon(s)...  
 *   Autostarting VPN 'server'
 
############ syslog #######################
Jul  3 10:05:00 server ovpn-server[1198]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
Jul  3 10:05:00 server ovpn-server[1199]: UDPv4 link local: [undef]
Jul  3 10:05:00 server ovpn-server[1199]: UDPv4 link remote: [AF_INET]{ip address}:{port}
Jul  3 10:05:00 server ovpn-server[1199]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jul  3 10:05:03 server ovpn-server[1199]: [VPN] Peer Connection Initiated with [AF_INET]{ip address}:{port}
Jul  3 10:05:05 server ovpn-server[1199]: TUN/TAP device tun0 opened
Jul  3 10:05:05 server ovpn-server[1199]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jul  3 10:05:05 server ovpn-server[1199]: /sbin/ip link set dev tun0 up mtu 1500
Jul  3 10:05:05 server ovpn-server[1199]: /sbin/ip addr add dev tun0 local 10.102.1.6 peer 10.102.1.5
Jul  3 10:05:05 server ovpn-server[1199]: ERROR: Linux route add command failed: external program exited with error status: 2
Jul  3 10:05:05 server ovpn-server[1199]: Initialization Sequence Completed

######### Routing table while VPN is active ################
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.102.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.250   0.0.0.0         UG    0      0        0 eth0
10.102.1.1      10.102.1.5      255.255.255.255 UGH   0      0        0 tun0
10.102.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
{vpn server}    192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.102.1.5      128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

######### Stop VPN ################################
 * Stopping virtual private network daemon(s)... 
 *   Stopping VPN 'server' [ OK ]

######### syslog ###################################
Jul  3 10:09:46 server ovpn-server[1199]: event_wait : Interrupted system call (code=4)
Jul  3 10:09:46 server ovpn-server[1199]: /sbin/ip addr del dev tun0 local 10.102.1.6 peer 10.102.1.5
Jul  3 10:09:46 server ovpn-server[1199]: SIGTERM[hard,] received, process exiting

############ Routing table after VPN has stopped ###############
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.250   0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

I am having no problem connecting, and the VPN acts exactly as expected during operation. The only problem I have is when the VPN closes, the following line I expect to see in the routing table is not:

{vpn server} 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0

Traffic

grogling wroteIs there a way of having the client report any configuration pushed down from the server?

Set --verb 4 in your config and look for pushed options ...

grogling wrotethe VPN acts exactly as expected during operation. The only problem I have is when the VPN closes, the following line I expect to see in the routing table is not:

{vpn server} 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0

It is probably removed when the VPN closes as it coincides with route added when the server redirects your gateway.

The only answer I can offer is to run a script to start OpenVPN and when the VPN closes have the script add the route back ...

One other thing, which does not effect you as you are using a commercial VPN, your Local LAN is 192.168.1.0/24 .. this is an extremely common subnet and is likely to cause routing conflicts if you ever run your own server.