Connection established but routing wrong

[M11G8sHzddoJONBjHxYVuhnmlw 0]

Hello,

 

I've been using AirVPN for a long time - at least I thought so. When I visited the website today, which I usually don't, I noticed that the central footer box on the page says "not connected", although my connection was listed as established in the Client Area section. First of all - and this is strange - I randomly visit a number of these what's-my-IP-pages and interestingly enough. Today I accidentally picked a one I hadn't chosen before and it, like the AirVPN footer, returned my ISP-IP.

 

I then began to enquire. I used to connect using the single .ovpn file for linux. My config was pretty much standard:

 

# --------------------------------------------------------
# Air VPN | https://airvpn.org | Thursday 25th of September 2014 07:30:38 AM
# OpenVPN Client Configuration
# AirVPN_Europe_UDP-443
# --------------------------------------------------------

client
dev tun
proto udp
remote europe.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
verb 3
explicit-exit-notify 5
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
</key>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

script-security 2
up /usr/share/openvpn/update-resolv-conf
down /usr/share/openvpn/update-resolv-conf

I regenerated this one today and, just to be safe, tried it both with and without the update-resolv-conf-section

 

I then looked up my routes and found something that should not be, Whilst the command line returns (see red line)

 

sudo openvpn AirVPN_Europe_UDP-443.ovpn
Thu Sep 25 11:20:39 2014 OpenVPN 2.3.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May  3 2014
Thu Sep 25 11:20:39 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.08
Thu Sep 25 11:20:39 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Sep 25 11:20:39 2014 Control Channel Authentication: tls-auth using INLINE static key file
Thu Sep 25 11:20:39 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 25 11:20:39 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 25 11:20:39 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Sep 25 11:20:39 2014 UDPv4 link local: [undef]
Thu Sep 25 11:20:39 2014 UDPv4 link remote: [AF_INET]95.211.186.65:443
Thu Sep 25 11:20:39 2014 TLS: Initial packet from [AF_INET]95.211.186.65:443, sid=691b8e21 8ff5b93d
Thu Sep 25 11:20:39 2014 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Thu Sep 25 11:20:39 2014 Validating certificate key usage
Thu Sep 25 11:20:39 2014 ++ Certificate has key usage  00a0, expects 00a0
Thu Sep 25 11:20:39 2014 VERIFY KU OK
Thu Sep 25 11:20:39 2014 Validating certificate extended key usage
Thu Sep 25 11:20:39 2014 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Sep 25 11:20:39 2014 VERIFY EKU OK
Thu Sep 25 11:20:39 2014 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
Thu Sep 25 11:20:41 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Sep 25 11:20:41 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 25 11:20:41 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Sep 25 11:20:41 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 25 11:20:41 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Thu Sep 25 11:20:41 2014 [server] Peer Connection Initiated with [AF_INET]95.211.186.65:443
Thu Sep 25 11:20:43 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Sep 25 11:20:43 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.49.202 10.4.49.201'
Thu Sep 25 11:20:43 2014 OPTIONS IMPORT: timers and/or timeouts modified
Thu Sep 25 11:20:43 2014 OPTIONS IMPORT: LZO parms modified
Thu Sep 25 11:20:43 2014 OPTIONS IMPORT: --ifconfig/up options modified
Thu Sep 25 11:20:43 2014 OPTIONS IMPORT: route options modified
Thu Sep 25 11:20:43 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Sep 25 11:20:43 2014 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp0s25 HWADDR=00:1f:16:18:ca:bb
Thu Sep 25 11:20:43 2014 TUN/TAP device tun0 opened
Thu Sep 25 11:20:43 2014 TUN/TAP TX queue length set to 100
Thu Sep 25 11:20:43 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Sep 25 11:20:43 2014 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Sep 25 11:20:43 2014 /usr/bin/ip addr add dev tun0 local 10.4.49.202 peer 10.4.49.201
Thu Sep 25 11:20:43 2014 /usr/share/openvpn/update-resolv-conf tun0 1500 1558 10.4.49.202 10.4.49.201 init
dhcp-option DNS 10.4.0.1
Thu Sep 25 11:20:43 2014 /usr/bin/ip route add 95.211.186.65/32 via 192.168.1.1
Thu Sep 25 11:20:43 2014 /usr/bin/ip route add 0.0.0.0/1 via 10.4.49.201 # <- seems right!
Thu Sep 25 11:20:43 2014 /usr/bin/ip route add 128.0.0.0/1 via 10.4.49.201
Thu Sep 25 11:20:43 2014 /usr/bin/ip route add 10.4.0.1/32 via 10.4.49.201
Thu Sep 25 11:20:43 2014 Initialization Sequence Completed

...all destinations are actually routed via the default LAN gateway:

 

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 enp0s25 # <- seems wrong!
10.4.0.1        10.4.49.201     255.255.255.255 UGH   20     0        0 tun0
10.4.49.201     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
95.211.186.65   192.168.1.1     255.255.255.255 UGH   0      0        0 enp0s25
128.0.0.0       10.4.49.201     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 enp0s25
192.168.1.0     0.0.0.0         255.255.255.0   U     203    0        0 enp0s25

This can hardly be intended behavior. Is it a misconfiguration on my side? Just for completeness sake: I also tried to establish a connection via network-manager which worked before (long time ago though), but received a timeout

 

journalctl -f
Sep 25 11:28:19 machine nm-openvpn[7987]: OpenVPN 2.3.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May  3 2014
Sep 25 11:28:19 machine nm-openvpn[7987]: library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.08
Sep 25 11:28:19 machine nm-openvpn[7987]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sep 25 11:28:19 machine nm-openvpn[7987]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 25 11:28:19 machine nm-openvpn[7987]: WARNING: file '/home/$USER/AirVPN/user.key' is group or others accessible
Sep 25 11:28:19 machine NetworkManager[427]: <info> VPN plugin state changed: starting (3)
Sep 25 11:28:19 machine NetworkManager[427]: <info> VPN connection 'AIRVPN' (ConnectInteractive) reply received.
Sep 25 11:28:20 machine nm-openvpn[7987]: UDPv4 link local: [undef]
Sep 25 11:28:20 machine nm-openvpn[7987]: UDPv4 link remote: [AF_INET]95.211.138.7:443
Sep 25 11:29:00 machine NetworkManager[427]: <warn> VPN connection 'AIRVPN' connect timeout exceeded.
Sep 25 11:29:00 machine nm-openvpn[7987]: SIGTERM[hard,] received, process exiting
Sep 25 11:29:00 machine NetworkManager[427]: nm-openvpn-Message: Terminated openvpn daemon with PID 7987.

edit: marking text in blocks does not seem to work. Added comments

 

edit2: Turns out, it is definitely a configuration problem on my side. 3 out of 4 /usr/bin/ip-calls failed without notice. Manually applying the routes that calling openvpn should have set resolves it.