Traffic not routing through vpn tun0

gevero

I normally use arch linux. I can route the traffic with openvpn by simply issuing "sudo openvpn file.ovpn" from command line, where "file.ovpn" is the file obtained with your config generator. Now I recently installed a manjaro distribution on my laptop. If I launch the vpn by issuing "sudo openvpn file.ovpn" everything seems to be fine, with the exception that no traffic is routed through the vpn and my ip is still visible. If I try to import the vpn from the kde vpn applet everything also seem to be fine, but the problem remains and my ip is still visible. Any ideas?

Best Regards

InactiveUser

After issuing "sudo openvpn file.ovpn", use "route -n" to check your default route.

Two routes have to be set correctly:

1. A new default route via the VPN device. Something similar to:

Destination....Gateway....Genmask....Flags....Metric....Ref....Use....Iface

0.0.0.0........10.X.X.X......0.0.0.0.....UG........1024......0........0........tun0

2. A route to the AirVPN server via the local gateway (your (W)LAN). Something similar to:

[AirVPN IP] .. 192.168.X.X .. 255.255.255.255 ............................. eth0

If you don't see these routes, try installing the "net-tools" packages from the Arch repos.

It contains the ifconfig tool, used by OpenVPN to set the routes.

OpenVPN can also be configured to use the newer ip / iproute2 command instead.

More info:

https://airvpn.org/topic/12031-vpn-problems-under-archlinux/?do=findComment&comment=19471

Staff

Hello!

@gevero

Besides the excellent suggestion by sheivoko, examine OpenVPN logs (feel free to post them), perhaps they might show precious clues for troubleshooting.

Kind regards

gevero

Hi

I got it working somehow. It was a strange interplay between dhclient and dhcpcd and the kde networkmanage applet. Now I have the vpn up and no dns leaks! Thanks a lot.

gevero

Hi

The problem I stated above presented itself again. Now openvpn works with the wired connection, but not with the wireless one. As suggested by sheivoko i checked the routes and actually

Destination....Gateway....Genmask....Flags....Metric....Ref....Use....Iface
0.0.0.0........10.X.X.X......0.0.0.0.....UG........1024......0........0........tun0

is not there, even if net-tools is correctly installed. I tried to check the openvpn logs, but despite my efforts I seem unable to locate them? How should I proced?

Thanks a lot

gevero

Here are the logs

Wed Sep 3 01:05:35 2014 OpenVPN 2.3.4 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on May 3 2014
Wed Sep 3 01:05:35 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.08
Wed Sep 3 01:05:35 2014 Control Channel Authentication: tls-auth using INLINE static key file
Wed Sep 3 01:05:35 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 3 01:05:35 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 3 01:05:35 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Wed Sep 3 01:05:35 2014 UDPv4 link local: [undef]
Wed Sep 3 01:05:35 2014 UDPv4 link remote: [AF_INET]184.75.221.2:443
Wed Sep 3 01:05:35 2014 TLS: Initial packet from [AF_INET]184.75.221.2:443, sid=9e59deaf 9aacc387
Wed Sep 3 01:05:35 2014 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Wed Sep 3 01:05:35 2014 Validating certificate key usage
Wed Sep 3 01:05:35 2014 ++ Certificate has key usage 00a0, expects 00a0
Wed Sep 3 01:05:35 2014 VERIFY KU OK
Wed Sep 3 01:05:35 2014 Validating certificate extended key usage
Wed Sep 3 01:05:35 2014 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Sep 3 01:05:35 2014 VERIFY EKU OK
Wed Sep 3 01:05:35 2014 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
Wed Sep 3 01:05:38 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Sep 3 01:05:38 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 3 01:05:38 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Sep 3 01:05:38 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 3 01:05:38 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Wed Sep 3 01:05:38 2014 [server] Peer Connection Initiated with [AF_INET]184.75.221.2:443
Wed Sep 3 01:05:40 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Sep 3 01:05:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.4.0.1,comp-lzo no,route 10.4.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.4.71.30 10.4.71.29'
Wed Sep 3 01:05:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed Sep 3 01:05:41 2014 OPTIONS IMPORT: LZO parms modified
Wed Sep 3 01:05:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed Sep 3 01:05:41 2014 OPTIONS IMPORT: route options modified
Wed Sep 3 01:05:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Sep 3 01:05:41 2014 ROUTE_GATEWAY 172.22.255.254/255.255.0.0 IFACE=wifi0 HWADDR=7c:7a:91:b4:cc:6f
Wed Sep 3 01:05:41 2014 TUN/TAP device tun0 opened
Wed Sep 3 01:05:41 2014 TUN/TAP TX queue length set to 100
Wed Sep 3 01:05:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Sep 3 01:05:41 2014 /usr/bin/ip link set dev tun0 up mtu 1500
Wed Sep 3 01:05:41 2014 /usr/bin/ip addr add dev tun0 local 10.4.71.30 peer 10.4.71.29
Wed Sep 3 01:05:41 2014 /usr/bin/ip route add 184.75.221.2/32 via 172.22.255.254
Wed Sep 3 01:05:41 2014 /usr/bin/ip route add 0.0.0.0/1 via 10.4.71.29
Wed Sep 3 01:05:41 2014 /usr/bin/ip route add 128.0.0.0/1 via 10.4.71.29
Wed Sep 3 01:05:41 2014 /usr/bin/ip route add 10.4.0.1/32 via 10.4.71.29
Wed Sep 3 01:05:41 2014 Initialization Sequence Completed

Apparently openvpn is using ip / iproute2 alresdy

drawl

I'm also a manjaro user and I'm having the very same problem. Connection comes up and is rock solid over both TCP and UDP. Yet the applet on the site shows that I'm not connected. no traffic is routed through the vpn and my ip is still visible. Has anyone found a solution to this?

Regards

george493

Have you tried rebooting OS, and router?

zebulon

I also use Archlinux 64 bits, and got the same issue. The airvpn application works fine though. So I started to compare the routing between the tunnel created with the airvpn software and openvpn in command line.

Before activating the VPN, route -n gives me:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 wlan0

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0

Then I use this command:

sudo openvpn AirVPN_Europe_UDP-443.ovpn

to create the VPN tunnel tun0 is indeed created, but the wifi does not use it. route -n gives me:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 wlan0

10.4.0.1 10.4.xx.yy 255.255.255.255 UGH 20 0 0 tun0

10.4.xx.yy 0.0.0.0 255.255.255.255 UH 0 0 0 tun0

37.aa.bb.cc 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0

128.0.0.0 10.4.xx.yy 128.0.0.0 UG 20 0 0 tun0

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0

Note xx.yy and aa.bb.cc are variable depending on the server you connect.

There is an issue with the order of the routing entries.

If I now type in console:

/usr/bin/ip route add 0.0.0.0/1 via 10.4.xx.yy

then I get correctly routed and AirVPN website shows I am connected to a VPN server. This is one of the lines openvpn otput when run.

route -n now shows:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 10.4.xx.yy 128.0.0.0 UG 0 0 0 tun0

0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 wlan0

10.4.0.1 10.4.xx.yy 255.255.255.255 UGH 20 0 0 tun0

10.4.xx.yy 0.0.0.0 255.255.255.255 UH 0 0 0 tun0

37.aa.bb.cc 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0

128.0.0.0 10.4.xx.yy 128.0.0.0 UG 20 0 0 tun0

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0

The key thing is to have

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 10.4.xx.yy 128.0.0.0 UG 0 0 0 tun0

as the first line of the routing table.

For some reason, openvpn does not create it in the correct order. I do not know yet if it is a bg in openvpn, the archlinux package or some interaction with networkmanager-openvpn on my KDE desktop.

Staff

I also use Archlinux 64 bits, and got the same issue. The airvpn application works fine though. So I started to compare the routing between the tunnel created with the airvpn software and openvpn in command line.
...
For some reason, openvpn does not create it in the correct order. I do not know yet if it is a bg in openvpn, the archlinux package or some interaction with networkmanager-openvpn on my KDE desktop.

Hello,

might it be that the OpenVPN version you run directly is not the same version run by Eddie? Compare OpenVPN logs version output in Eddie logs with OpenVPN logs version output when you run it directly.

Kind regards

iwih2gk

I got tired of worrying about this stuff. It may seem cryptic but I simply bring up UFW after the client connects and I use (IP tables via UFW) to simply restrict ALL traffic to tun0 (only one rule needed). Nothing but tun0 that way!

An added bonus is it isolates the tunnel machine from all other devices on the intra-net you are connected to. I suppose if you need inter connectivity it would be a bad thing, but for most it would be a solid bonus.

zebulon

I also use Archlinux 64 bits, and got the same issue. The airvpn application works fine though. So I started to compare the routing between the tunnel created with the airvpn software and openvpn in command line.
...
For some reason, openvpn does not create it in the correct order. I do not know yet if it is a bg in openvpn, the archlinux package or some interaction with networkmanager-openvpn on my KDE desktop.

Hello,

might it be that the OpenVPN version you run directly is not the same version run by Eddie? Compare OpenVPN logs version output in Eddie logs with OpenVPN logs version output when you run it directly.

Kind regards

I am using the openvpn packaged with Arch linux::

core/openvpn 2.3.6-1 [installed]

An easy-to-use, robust, and highly configurable VPN (Virtual Private Network)

$ openvpn --version

OpenVPN 2.3.6 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on Dec 2 2014

library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08

Originally developed by James Yonan

Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

zebulon

I also use Archlinux 64 bits, and got the same issue. The airvpn application works fine though. So I started to compare the routing between the tunnel created with the airvpn software and openvpn in command line.
...
For some reason, openvpn does not create it in the correct order. I do not know yet if it is a bg in openvpn, the archlinux package or some interaction with networkmanager-openvpn on my KDE desktop.

Hello,

might it be that the OpenVPN version you run directly is not the same version run by Eddie? Compare OpenVPN logs version output in Eddie logs with OpenVPN logs version output when you run it directly.

Kind regards

Sorry, who is Eddie?

Thanks.

iwih2gk

Eddie is our AirVpn client's name. Sorry we toss that around here as if everyone on the planet should know what it means.

zebulon

Eddie is our AirVpn client's name. Sorry we toss that around here as if everyone on the planet should know what it means.

Makes sense. Now I understand what you meant. Anyway, I am also active on Archlinux forums, so I will see if something can be learned there as well.

manyways76

I think I'm having the same issue: after upgrading to Fedora 21, . OpenVPN version is:

$ openvpn --version
OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
library versions: OpenSSL 1.0.1j-fips 15 Oct 2014, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_pthread=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

My log:

# openvpn --config AirVPN_All-servers_UDP-443.ovpn
Sat Dec 13 12:11:05 2014 OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
Sat Dec 13 12:11:05 2014 library versions: OpenSSL 1.0.1j-fips 15 Oct 2014, LZO 2.08
Sat Dec 13 12:11:05 2014 Control Channel Authentication: tls-auth using INLINE static key file
Sat Dec 13 12:11:05 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 13 12:11:05 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 13 12:11:05 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sat Dec 13 12:11:05 2014 UDPv4 link local: [undef]
Sat Dec 13 12:11:05 2014 UDPv4 link remote: [AF_INET]37.48.80.129:443
Sat Dec 13 12:11:05 2014 TLS: Initial packet from [AF_INET]37.48.80.129:443, sid=864e4cde 8ad024c6
Sat Dec 13 12:11:05 2014 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Sat Dec 13 12:11:05 2014 Validating certificate key usage
Sat Dec 13 12:11:05 2014 ++ Certificate has key usage  00a0, expects 00a0
Sat Dec 13 12:11:05 2014 VERIFY KU OK
Sat Dec 13 12:11:05 2014 Validating certificate extended key usage
Sat Dec 13 12:11:05 2014 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Dec 13 12:11:05 2014 VERIFY EKU OK
Sat Dec 13 12:11:05 2014 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
Sat Dec 13 12:11:06 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Dec 13 12:11:06 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 13 12:11:06 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Dec 13 12:11:06 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Dec 13 12:11:06 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 AES128-SHA, 4096 bit RSA
Sat Dec 13 12:11:06 2014 [server] Peer Connection Initiated with [AF_INET]37.48.80.129:443
Sat Dec 13 12:11:09 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Dec 13 12:11:09 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.4.0.1,comp-lzo no,route 10.4.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.4.66.162 10.4.66.161'
Sat Dec 13 12:11:09 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Dec 13 12:11:09 2014 OPTIONS IMPORT: LZO parms modified
Sat Dec 13 12:11:09 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Dec 13 12:11:09 2014 OPTIONS IMPORT: route options modified
Sat Dec 13 12:11:09 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Dec 13 12:11:09 2014 ROUTE_GATEWAY 192.168.100.1/255.255.255.0 IFACE=wlp3s0 HWADDR=4c:80:93:66:b2:64
Sat Dec 13 12:11:09 2014 TUN/TAP device tun0 opened
Sat Dec 13 12:11:09 2014 TUN/TAP TX queue length set to 100
Sat Dec 13 12:11:09 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Dec 13 12:11:09 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Sat Dec 13 12:11:09 2014 /usr/sbin/ip addr add dev tun0 local 10.4.66.162 peer 10.4.66.161
Sat Dec 13 12:11:09 2014 /usr/sbin/ip route add 37.48.80.129/32 via 192.168.100.1
Sat Dec 13 12:11:09 2014 /usr/sbin/ip route add 0.0.0.0/1 via 10.4.66.161
Sat Dec 13 12:11:09 2014 /usr/sbin/ip route add 128.0.0.0/1 via 10.4.66.161
Sat Dec 13 12:11:09 2014 /usr/sbin/ip route add 10.4.0.1/32 via 10.4.66.161
Sat Dec 13 12:11:09 2014 Initialization Sequence Completed

Eddie also doesn't work with "Routing checking failed", but please note that airvpn.org is blocked in my country, so it might be that:

I 2014.12.13 12:13:31 - AirVPN client version: 2.7, System: Linux, Architecture: x64
. 2014.12.13 12:13:31 - Reading options from /home/.../.airvpn/AirVPN.xml
. 2014.12.13 12:13:31 - Data Path: /home/.../.airvpn
. 2014.12.13 12:13:31 - App Path: /usr/lib64/AirVPN
. 2014.12.13 12:13:31 - Executable Path: /usr/lib64/AirVPN/AirVPN.exe
. 2014.12.13 12:13:31 - Command line arguments: path="/home/.../.airvpn"
. 2014.12.13 12:13:32 - Operating System: Unix 3.17.4.302 - Linux localhost.localdomain 3.17.4-302.fc21.x86_64 #1 SMP Thu Dec 4 19:12:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
I 2014.12.13 12:13:32 - OpenVPN Driver - Found
I 2014.12.13 12:13:32 - OpenVPN - Version: OpenVPN 2.3.6 (/usr/sbin/openvpn)
I 2014.12.13 12:13:32 - SSH - Version: OpenSSH_6.6.1p1, OpenSSL 1.0.1j-fips 15 Oct 2014 (/usr/bin/ssh)
I 2014.12.13 12:13:32 - SSL - Version: stunnel 5.06 (/usr/lib64/AirVPN/stunnel)
I 2014.12.13 12:13:32 - IPV6: Available
! 2014.12.13 12:13:32 - Ready
I 2014.12.13 12:13:36 - Session starting.
! 2014.12.13 12:13:36 - Checking environment
! 2014.12.13 12:13:36 - Waiting for latency tests (8 to go)
! 2014.12.13 12:13:36 - Waiting for latency tests (6 to go)
! 2014.12.13 12:13:36 - Waiting for latency tests (5 to go)
! 2014.12.13 12:13:39 - Waiting for latency tests (4 to go)
! 2014.12.13 12:13:39 - Waiting for latency tests (3 to go)
! 2014.12.13 12:13:44 - Waiting for latency tests (2 to go)
! 2014.12.13 12:13:44 - Waiting for latency tests (1 to go)
! 2014.12.13 12:13:45 - Checking authorization ...
. 2014.12.13 12:13:45 - Checking authorization ..., 1° try failed (The remote server returned an error: (403) Forbidden.)
! 2014.12.13 12:13:46 - Connecting to Dorsum (Netherlands, Amsterdam)
. 2014.12.13 12:13:46 - OpenVPN > OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
. 2014.12.13 12:13:46 - OpenVPN > library versions: OpenSSL 1.0.1j-fips 15 Oct 2014, LZO 2.08
. 2014.12.13 12:13:46 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2014.12.13 12:13:46 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2014.12.13 12:13:46 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2014.12.13 12:13:46 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2014.12.13 12:13:46 - OpenVPN > Socket Buffers: R=[212992->131072] S=[212992->131072]
. 2014.12.13 12:13:46 - OpenVPN > UDPv4 link local: [undef]
. 2014.12.13 12:13:46 - OpenVPN > UDPv4 link remote: [AF_INET]95.211.149.195:443
. 2014.12.13 12:13:46 - OpenVPN > TLS: Initial packet from [AF_INET]95.211.149.195:443, sid=9f8d804f d062269f
. 2014.12.13 12:13:46 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2014.12.13 12:13:46 - OpenVPN > Validating certificate key usage
. 2014.12.13 12:13:46 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2014.12.13 12:13:46 - OpenVPN > VERIFY KU OK
. 2014.12.13 12:13:46 - OpenVPN > Validating certificate extended key usage
. 2014.12.13 12:13:46 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2014.12.13 12:13:46 - OpenVPN > VERIFY EKU OK
. 2014.12.13 12:13:46 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2014.12.13 12:13:47 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2014.12.13 12:13:47 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2014.12.13 12:13:47 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2014.12.13 12:13:47 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2014.12.13 12:13:47 - OpenVPN > Control Channel: TLSv1, cipher TLSv1/SSLv3 AES128-SHA, 4096 bit RSA
. 2014.12.13 12:13:47 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]95.211.149.195:443
. 2014.12.13 12:13:49 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2014.12.13 12:13:49 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.4.0.1,comp-lzo no,route 10.4.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.4.138.58 10.4.138.57'
. 2014.12.13 12:13:49 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2014.12.13 12:13:49 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2014.12.13 12:13:49 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2014.12.13 12:13:49 - OpenVPN > OPTIONS IMPORT: route options modified
. 2014.12.13 12:13:49 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2014.12.13 12:13:49 - OpenVPN > ROUTE_GATEWAY 192.168.100.1/255.255.255.0 IFACE=wlp3s0 HWADDR=4c:80:93:66:b2:64
. 2014.12.13 12:13:49 - OpenVPN > TUN/TAP device tun0 opened
. 2014.12.13 12:13:49 - OpenVPN > TUN/TAP TX queue length set to 100
. 2014.12.13 12:13:49 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip link set dev tun0 up mtu 1500
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip addr add dev tun0 local 10.4.138.58 peer 10.4.138.57
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip route add 95.211.149.195/32 via 192.168.100.1
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip route add 0.0.0.0/1 via 10.4.138.57
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip route add 128.0.0.0/1 via 10.4.138.57
. 2014.12.13 12:13:49 - OpenVPN > /usr/sbin/ip route add 10.4.0.1/32 via 10.4.138.57
. 2014.12.13 12:13:49 - Starting Management Interface
. 2014.12.13 12:13:49 - OpenVPN > Initialization Sequence Completed
I 2014.12.13 12:13:49 - /etc/resolv.conf renamed to /etc/resolv.conf.airvpn as backup
I 2014.12.13 12:13:49 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated)
! 2014.12.13 12:13:49 - Flushing DNS
! 2014.12.13 12:13:49 - Checking route
W 2014.12.13 12:13:59 - Checking route, 1° try failed (The request timed out)
E 2014.12.13 12:14:00 - Routing checking failed.
. 2014.12.13 12:14:00 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
! 2014.12.13 12:14:00 - Disconnecting
. 2014.12.13 12:14:00 - Management - Send 'signal SIGTERM'
. 2014.12.13 12:14:00 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2014.12.13 12:14:00 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2014.12.13 12:14:00 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
. 2014.12.13 12:14:00 - OpenVpn Management > SUCCESS: signal SIGTERM thrown
. 2014.12.13 12:14:05 - OpenVPN > /usr/sbin/ip route del 10.4.0.1/32
. 2014.12.13 12:14:05 - OpenVPN > /usr/sbin/ip route del 95.211.149.195/32
. 2014.12.13 12:14:05 - OpenVPN > /usr/sbin/ip route del 0.0.0.0/1
. 2014.12.13 12:14:05 - OpenVPN > RTNETLINK answers: No such process
. 2014.12.13 12:14:05 - OpenVPN > ERROR: Linux route delete command failed: external program exited with error status: 2
. 2014.12.13 12:14:05 - OpenVPN > /usr/sbin/ip route del 128.0.0.0/1
. 2014.12.13 12:14:05 - OpenVPN > Closing TUN/TAP interface
. 2014.12.13 12:14:05 - OpenVPN > /usr/sbin/ip addr del dev tun0 local 10.4.138.58 peer 10.4.138.57
. 2014.12.13 12:14:05 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2014.12.13 12:14:05 - Connection terminated.
I 2014.12.13 12:14:05 - DNS of the system restored to original settings (Rename method)
I 2014.12.13 12:14:06 - Cancel requested.
! 2014.12.13 12:14:06 - Session terminated.

zsxawerdu

I am having the same problem here too. I did what zuburon mention, and it worked, my ip is being routed correctly now.

Can someone please look at why openvpn is doing this? This is way over my head.

Staff

Hello,

as suggested by zsxawerdu the directive "route-delay 5" solves the problem. Fedora 21 users can enter that custom directive on their Eddie clients, or on the Configuration Generator. We're considering whether to put a "route-delay" directive as default (for Linux only) in the next client release and in the Configuration Generator.

Kind regards

ishap

Just installed on the new build (Ubuntu 14.04.1 64bit) and have been trying to get airvpn up and running but was running into the same problems as described above, "route-delay 5" solved it after trying all sorts for the last day. The funny thing is that it worked fine without route-delay on my old install using xubuntu 14.04 upgraded to 14.04.1

Just a mention as well, it seems the Eddie client has a dependency for resolvconf package. I was using openresolv.

Traffic not routing through vpn tun0

Recommended Posts

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Join the conversation