[Solved] remove routes when tunnel is down

hindmost

I have a group of routes that are added from the openvpn config file when the tunnel connects.

However, these routes remain when the tunnel loses its connection. I would like the routes to be removed until the tunnel re-connects. I cannot find a config option which enables this. I know you can call a script with "down" but "down" appears to mean openvpn has been shut down rather than the tunnel is down.

Thanks for any ideas.

# server config
dev tun
proto tcp-server
port 5555
ifconfig 192.168.252.1 192.168.252.2
route 192.168.100.0 255.255.255.0
route 192.168.200.0 255.255.255.0
secret /etc/openvpn/key
keepalive 10 60
daemon
persist-tun
comp-lzo
verb 4
mute 20
status ./log.txt
socket-flags TCP_NODELAY

----------------------------------------------------------

# client config
client
dev tun
proto tcp-client
remote 199.99.99.1 5555
comp-lzo
ifconfig 192.168.252.2 192.168.252.1
keepalive 10 60
route 192.168.100.0 255.255.255.0
route 192.168.200.0 255.255.255.0
socket-flags TCP_NODELAY
resolv-retry infinite
nobind
script-security 2
user nobody
group nobody
persist-key
persist-tun
secret /etc/openvpn/key
verb 4
mute 20

Mimiko

Hello.

The routes are added and delete automatically by OpenVPN.

Post log from OpenVPN where routes are not deleted. Use "verb 3" to log them.

Mimiko

I see that you use

route 192.168.100.0 255.255.255.0
route 192.168.200.0 255.255.255.0

On both, client and server. Which lan where is?

hindmost

100.0 is on the server side
200.0 is on the client side

Also, I enabled the higher level logging and when the tunnel is brought online the routes are added as expected but when the tunnel loses it's connection there are no entries indicating openvpn is trying to remove the routes while it tries to re-connect.

it just says attempting to establish TCP connection...

Also, please understand I am not talking about the routes not being removed when openvpn is stopped as in "service openvpn stop". When openvpn is stopped the routes go away - no problem.

I want the routes to go away when the tunnel connection is lost and to come back when openvpn re-establishes the tunnel.

Mimiko

--route network/IP [netmask] [gateway] [metric]
Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.

--persist-tun
Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts.
SIGUSR1 is a restart signal similar to SIGHUP, but which offers finer-grained control over reset options.

So, remove "persist-tun" option from config file on computer that need's to act like you want.

hindmost

[/quote]
So, remove "persist-tun" option from config file on computer that need's to act like you want.[/quote]

Yes, that causes the routes and tun0 to go away when openvpn realizes the tunnel is down.

However, it re-adds the routes and creates a new tun0 when it starts trying to re-connect. The problem for me is the routes are created before the tunnel is actually online.

Bebop

hindmost wroteThe problem for me is the routes are created before the tunnel is actually online.

Instead of hardcoding routes into the client config file, you can put them in an "up" script, which will be called after the tunnel goes up.

When using this method, a "down" script can be used to pull the routes down when your client closes the tunnel.

or you can just use "--up" and "--down" directives, which would also allow for you to include delays, so you can be sure the tunnel has a few seconds grace. More info in the man page.

Mimiko

Firstly, delete from server's config option "route 192.168.200.0 255.255.255.0 ".
Delete from client's config option "route 192.168.100.0 255.255.255.0 "
Then, comment "persist-tun".

I've made some checks. Routes are deleted by client's OpenVPN as fast as it finds that tunnel is no more valide. By option "keepalive 10 60" - about 60 seconds (second parameter). And re-added when connection is really established.

It will be much better, if you describe why you are concerned about those routes?

hindmost

Mimiko wroteFirstly, delete from server's config option "route 192.168.200.0 255.255.255.0 ".
Delete from client's config option "route 192.168.100.0 255.255.255.0 "
Then, comment "persist-tun".

I've made some checks. Routes are deleted by client's OpenVPN as fast as it finds that tunnel is no more valide. By option "keepalive 10 60" - about 60 seconds (second parameter). And re-added when connection is really established.

It will be much better, if you describe why you are concerned about those routes?

Ok, I will try the changes suggested.

The server and client machines are gateways to other networks of course and if the routes exist when the tunnel is not actually connected, traffic does not flow even though there are other routes available with higher metrics configured. If I manually remove the routes when the tunnel is not connected, traffic will flow through the other routes.

Thanks for the ideas.

hindmost

hindmost wrote
Mimiko wroteFirstly, delete from server's config option "route 192.168.200.0 255.255.255.0 ".
Delete from client's config option "route 192.168.100.0 255.255.255.0 "
Then, comment "persist-tun".

I've made some checks. Routes are deleted by client's OpenVPN as fast as it finds that tunnel is no more valide. By option "keepalive 10 60" - about 60 seconds (second parameter). And re-added when connection is really established.
?

Unfortunately, the behavior is the same. The routes are deleted but are immediately recreated when it starts trying to connect. The routes are added back even if you continually get the message
"TCP: connect to xxx.xxx.xxx.xxx:5555 failed, will try again in 5 seconds: Connection timed out"

It seems route addition/deletion and also the execution of "up" and "down" are solely based on the creation and deletion of the tun interface and has nothing to do with whether a connection is actually working or not.

Bebop

hindmost wrote also the execution of "up" and "down" are solely based on the creation and deletion of the tun interface and has nothing to do with whether a connection is actually working or not.

May be of some use:

--up-delay
Delay TUN/TAP open and possible --up script execution until after TCP/UDP connection establishment with peer.

In --proto udp mode, this option normally requires the use of --ping to allow connection initiation to be sensed in the absence of tunnel data, since UDP is a "connectionless" protocol.

On Windows, this option will delay the TAP-Win32 media state transitioning to "connected" until connection establishment, i.e. the receipt of the first authenticated packet from the peer.

Although I don't see an equivalent function for the down script, which in your case, you need.

Mimiko

Do you try this on a OpenVPN server?

If only at client, you cane push routes from server:

push "route 192.168.200.0"

hindmost

Bebop wrote
hindmost wrote also the execution of "up" and "down" are solely based on the creation and deletion of the tun interface and has nothing to do with whether a connection is actually working or not.

May be of some use:

--up-delay
Delay TUN/TAP open and possible --up script execution until after TCP/UDP connection establishment with peer.

In --proto udp mode, this option normally requires the use of --ping to allow connection initiation to be sensed in the absence of tunnel data, since UDP is a "connectionless" protocol.

On Windows, this option will delay the TAP-Win32 media state transitioning to "connected" until connection establishment, i.e. the receipt of the first authenticated packet from the peer.
Although I don't see an equivalent function for the down script, which in your case, you need.

That did it.

Adding "up-restart" , "up-delay" and the "up" and "down" scripts to add and remove the routes worked perfectly. Now the routes are only present when the tunnel is actually functional.
I think the "down" script also pays attention to the "up-delay" setting.

Thank you VERY much.

Bebop

hindmost wroteThat did it.

Those 3 words together, I like ^^

Well persistence pays, you are the proof of that. Well done and congrats. Hope it stays solved.

Mimiko

I think "up-restart" do you up and down scripts on restarts, as stated from OpenVPN manual.