Opened 7 years ago

Closed 7 years ago

#292 closed Bug / Defect (notabug)

OpenVPN client fails to reconnect after internet downtime

Reported by: dankegel Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.2.1 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

Using the openvpn-2.2.1 that comes with Ubuntu 12.04, I can connect
happily and reliably... but if the internet is having a bad day,
there are two problems when the internet comes back. In the log I
see

Wed May 15 11:14:43 2013 RESOLVE: Cannot resolve host address: foovpn.foobar.net: [HOST_NOT_FOUND] The specified host is unknown.

This persists even after the internet comes back. I can't access
anything via the vpn at this point, and since openvpn has replaced
/etc/resolv.conf with something that points to DNS servers on
the VPN, it's hosed! It can't even try to connect again.

If I manually edit /etc/resolv.conf to restore it to its original
state, the next time around, openvpn does manage to connect, but
then things fail with:

...

Wed May 15 11:17:41 2013 /sbin/route del -net 10.10.0.0 netmask 255.255.0.0
Wed May 15 11:17:41 2013 Closing TUN/TAP interface
Wed May 15 11:17:41 2013 /sbin/ifconfig tun0 0.0.0.0
Wed May 15 11:17:41 2013 /etc/openvpn/updown_hooks.sh tun0 1500 1542 10.18.112.18 10.18.112.17 init
Wed May 15 11:17:41 2013 WARNING: Failed running command (--up/--down): external program exited with error status: 1
Wed May 15 11:17:41 2013 Exiting

This last part vaguely reminds me of
https://community.openvpn.net/openvpn/ticket/203

Change History (4)

comment:1 Changed 7 years ago by krzee king

Last edited 7 years ago by krzee king (previous) (diff)

comment:2 Changed 7 years ago by JoshC

If you are using a DNS name for the --remote value, it will need to be available via OS name resolution when the client connects or reconnects. If it isn't, the connection will fail.

On Linux/Unix? systems, OpenVPN does not change DNS settings upon connection and an --up/--down script needs to handle this. In the event of reconnects where the DNS settings remain unchanged and the modified settings are unavailable after the VPN goes down, an endless cycle of failed reconnect attempts is the result.

There are effectively 2 ways to fix that: either don't change the DNS settings on connect, or remove them on reconnects by using the --down and --up-restart options, which will call --up and --down scripts on restarts as well as init and termination. Note that after initial startup these scripts will be run without root permission when --user and/or --group.

The problem could also be avoided by using an IP, perhaps as a fallback <connection> profile.

comment:3 Changed 7 years ago by JoshC

Priority: majorminor

comment:4 Changed 7 years ago by JoshC

Resolution: notabug
Status: newclosed

Without any follow-up in 4 weeks, this bug is being marked closed. If you wish to follow-up or re-open the bug, feel free to supply additional relevant details.

Note: See TracTickets for help on using tickets.