[SOLVED]: Odd issue with OpenVPN

MariusMatutiae · 2014-11-20 10:26:58

I have the following issue with OpenVPN: I connect correctly to my server, but *occasionally* the routing table is not properly updated, despite OpenVPN' log showing the correct push option.

You can see below that the two routes

ip route add 0.0.0.0/1 via 10.8.73.5 dev tun0
ip route add 128.0.0.0/1 via 10.8.73.5 dev tun0

are pushed by the server, but they are nowhere to be seen in the routing table.

# uname -a
Linux jiggs 3.17.3-1-ARCH #1 SMP PREEMPT Fri Nov 14 23:13:48 CET 2014 x86_64 GNU/Linux
]# ip route show
default via 192.168.1.1 dev wlan0  proto static  metric 1024 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.100 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.100  metric 303 
# openvpn --config myconfig.conf &
Thu Nov 20 10:50:44 2014 OpenVPN 2.3.5 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Oct 30 2014
Thu Nov 20 10:50:44 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Thu Nov 20 10:50:44 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Nov 20 10:50:44 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Nov 20 10:50:44 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Nov 20 10:50:44 2014 UDPv4 link local: [undef]
Thu Nov 20 10:50:44 2014 UDPv4 link remote: [AF_INET]MY.IP.ADD.RESS:21113
Thu Nov 20 10:50:44 2014 TLS: Initial packet from [AF_INET]MY.IP.ADD.RESS:21113, sid=602edc93 120e0fb8
Thu Nov 20 10:50:44 2014 VERIFY OK: depth=1, C=xx, ST=xx, L=xx, OU=changeme, CN=changeme, name=changeme
Thu Nov 20 10:50:44 2014 VERIFY OK: depth=0, C=xx, ST=xx, L=xx, OU=changeme, CN=changeme, name=changeme
Thu Nov 20 10:50:45 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 20 10:50:45 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 20 10:50:45 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 20 10:50:45 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 20 10:50:45 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 20 10:50:45 2014 [changeme] Peer Connection Initiated with [AF_INET]MY.IP.ADD.RESS:21113
Thu Nov 20 10:50:47 2014 SENT CONTROL [changeme]: 'PUSH_REQUEST' (status=1)
Thu Nov 20 10:50:47 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 192.168.73.0 255.255.255.0,dhcp-option DNS 192.168.73.1,dhcp-option DOMAIN my.lan,route 10.8.73.0 255.255.255.0,topology net30,ping 10,ping-restart 60,ifconfig 10.8.73.6 10.8.73.5'
Thu Nov 20 10:50:47 2014 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 20 10:50:47 2014 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 20 10:50:47 2014 OPTIONS IMPORT: route options modified
Thu Nov 20 10:50:47 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 20 10:50:47 2014 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=00:26:c6:09:cb:3e
Thu Nov 20 10:50:47 2014 TUN/TAP device tun0 opened
Thu Nov 20 10:50:47 2014 TUN/TAP TX queue length set to 100
Thu Nov 20 10:50:47 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Nov 20 10:50:47 2014 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Nov 20 10:50:47 2014 /usr/bin/ip addr add dev tun0 local 10.8.73.6 peer 10.8.73.5
Thu Nov 20 10:50:47 2014 /etc/openvpn/update-resolv-conf tun0 1500 1542 10.8.73.6 10.8.73.5 init
dhcp-option DNS 192.168.73.1
dhcp-option DOMAIN my.lan
Thu Nov 20 10:50:47 2014 /usr/bin/ip route add MY.IP.ADD.RESS/32 via 192.168.1.1
Thu Nov 20 10:50:47 2014 /usr/bin/ip route add 0.0.0.0/1 via 10.8.73.5
Thu Nov 20 10:50:47 2014 /usr/bin/ip route add 128.0.0.0/1 via 10.8.73.5
Thu Nov 20 10:50:47 2014 /usr/bin/ip route add 192.168.73.0/24 via 10.8.73.5
Thu Nov 20 10:50:47 2014 /usr/bin/ip route add 10.8.73.0/24 via 10.8.73.5
Thu Nov 20 10:50:47 2014 Initialization Sequence Completed
# ip route show
default via 192.168.1.1 dev wlan0  proto static  metric 1024 
10.8.73.5 dev tun0  proto kernel  scope link  src 10.8.73.6 
MY.IP.ADD.RESS via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.100

The OpenVPN server.conf file

port 21113
proto udp
dev tun

ca      /etc/openvpn/ca.crt    # generated keys
cert    /etc/openvpn/server.crt
key     /etc/openvpn/server.key  # keep secret
dh      /etc/openvpn/dh1024.pem

server 10.8.73.0 255.255.255.0  # internal tun0 connection IP
push "redirect-gateway def1"
push "route 192.168.73.0 255.255.255.0"
push "dhcp-option DNS 192.168.73.1"
push "dhcp-option DOMAIN my.lan"
ifconfig-pool-persist ipp.txt

keepalive 10 120

comp-lzo        
persist-key
persist-tun

status log/openvpn-status.log
log-append /var/log/openvpn.log

verb 4  # verbose mode
client-to-client
keepalive 10 60
duplicate-cn

and the client conf file:

client
dev tun
port 21113
proto udp

remote MY.IP.ADD.RESS
nobind

ca /home/myname/openvpn/ca.crt
cert /home/myname/openvpn/myname.crt
key /home/myname/openvpn/myname.key


comp-lzo
persist-key
persist-tun

verb 3
#daemon

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Both are quite simple and standard.

The two questions I have:

1) Any hint on what is going on?

2) It looks to me like a bug, but where? I would gladly report it, but to whom? Choices are OpenVPN, iproute2, Linux Kernel. Any suggestion? But my first attempt is here, because I have two other laptops, Debian and Kubuntu, with identical client.conf files, which, when connecting to the same server, **never** display such issues.

I have installed openvpn from the repos, openvpn-2.3.5-1.

Last edited by MariusMatutiae (2014-11-21 18:33:42)

brebs · 2014-11-20 16:00:18

MariusMatutiae wrote:

Thu Nov 20 10:50:47 2014 /usr/bin/ip route add 0.0.0.0/1 via 10.8.73.5

0.0.0.0/1 is a nonsense route - figure out how/why that's included, and remove it

MariusMatutiae · 2014-11-20 17:04:16

Afraid not, brebs. That's the way more recent versions of OpenVPN perform redirection of all traffic through the server.

Rather than changing the default router, they add these two barely less general routes which, according to the usual rules of routing tables, take precedence over the default gateway, and all traffic now goes through the OpenVPN server. In fact, it is exactly when I have both these routes in effect that my public IP is identified by the usual various services, as my server's IP, not my client's.

brebs · 2014-11-20 17:27:07

Oh, OK. What a hack

This "occasionally" - do you mean on startup, or when the link is *renewed*?

You could try e.g. Debian's version, with Debian's several patches.

"client_hang_when_server_dont_push.patch" looks most promising.

MariusMatutiae · 2014-11-20 20:09:24

You are right, should have made it clearer: *occasionally* means upon renewal, but not upon every renewal.

I will try Debian's version, thanks, will let you know.

MariusMatutiae · 2014-11-21 18:37:33

Strange thing: I recompiled from source, downloaded from the Openvpn site, here, and this does not suffer from the same problem. Since the version is identical to those in the repo, I have troubles understanding the origin of this problem. But at any rate, the problem is now marked as solved.

Incidentally, the Debian version has so many dependencies, it turns out it is much easier to recompile the original Linux source, as stated above.

brebs · 2014-11-21 18:42:24

It is not impossible that a recompilation can improve reliability, when e.g. other libs that openvpn uses have changed.

Is your compiled executable *identical* to Arch's distributed executable? It may be worth filing a bug, just to tell the Arch devs to recompile this app.

MariusMatutiae · 2014-11-22 06:24:30

No, it is not identical: they have different hashes. I will file the bug, thanks for the suggestion.

qft · 2014-12-23 09:10:41

MariusMatutiae wrote:

No, it is not identical: they have different hashes. I will file the bug, thanks for the suggestion.

Hi I am having exactly the same problem. Do you know what's causing it by now? And do you have any other solutions than recompiling OpenVPN? Sorry I cannot seem to find your bug report in the bug tracker. Thank you very much!

qft · 2014-12-23 15:00:07

qft wrote:

MariusMatutiae wrote:
No, it is not identical: they have different hashes. I will file the bug, thanks for the suggestion.
Hi I am having exactly the same problem. Do you know what's causing it by now? And do you have any other solutions than recompiling OpenVPN? Sorry I cannot seem to find your bug report in the bug tracker. Thank you very much!

P.S. Recompiling OpenVPN does not really solve this problem for me...

Arch Linux

#1 2014-11-20 10:26:58

[SOLVED]: Odd issue with OpenVPN

#2 2014-11-20 16:00:18

Re: [SOLVED]: Odd issue with OpenVPN

#3 2014-11-20 17:04:16

Re: [SOLVED]: Odd issue with OpenVPN

#4 2014-11-20 17:27:07

Re: [SOLVED]: Odd issue with OpenVPN

#5 2014-11-20 20:09:24

Re: [SOLVED]: Odd issue with OpenVPN

#6 2014-11-21 18:37:33

Re: [SOLVED]: Odd issue with OpenVPN

#7 2014-11-21 18:42:24

Re: [SOLVED]: Odd issue with OpenVPN

#8 2014-11-22 06:24:30

Re: [SOLVED]: Odd issue with OpenVPN

#9 2014-12-23 09:10:41

Re: [SOLVED]: Odd issue with OpenVPN

#10 2014-12-23 15:00:07

Re: [SOLVED]: Odd issue with OpenVPN

Board footer