Random timeouts on clients, connection breaks down

[makedir]

I have a weird issue and I am going nuts. I tried mostly everything so far and I just cant find out whats wrong or where the error comes from.

In short, the behavior is this: I am browsing for example http(s) pages through Chrome, and suddenly, a new page doesn't load anymore and Chrome just says "establishing secure connection..." and then gives a TIMEOUT_ERROR. It also can happen, that during this wait phase, suddenly the page pops up. Then it works for some random time and then it is broken again.

Client config:

Code: Select all

client
dev tun
proto udp
remote 81.*.*.* 1194
engine cryptodev
resolv-retry infinite
nobind
persist-key
ca /etc/openvpn/keys/ca.ipvanish.com.crt
auth-user-pass /etc/openvpn/keys/user_ipvanish.auth
verify-x509-name **** name
script-security 2
route-noexec
route-up /etc/openvpn/up/route-up.sh
down /etc/openvpn/down/route-down.sh
comp-lzo no
verb 3
ncp-disable
auth SHA256
cipher AES-128-GCM
keysize 128
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-DSS-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA

route-up.sh:

Code: Select all

#!/bin/sh

if [[ $dev == 'tun0' ]]; then
  TABLE='vpn1'
else
  TABLE='vpn2'
fi

ip route flush table $TABLE
ip route add default via $route_vpn_gateway table $TABLE dev $dev
iptables -w -t nat -A POSTROUTING -o $dev -j SNAT --to $ifconfig_local

exit 0

route-down.sh:

Code: Select all

#!/bin/sh

if [[ $dev == 'tun0' ]]; then
  TABLE='vpn1'
else
  TABLE='vpn2'
fi

ip route flush table $TABLE
iptables -w -t nat -D POSTROUTING -o $dev -j SNAT --to $ifconfig_local

exit 0

routing rules:

Code: Select all

ip rule add prio 32764 fwmark 2 table vpn1
ip rule add prio 32763 fwmark 3 table vpn2

firewall:

Code: Select all

iptables -w -A forwarding_rule -i br-lan -o tun+ -j ACCEPT
iptables -w -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK --set-mark 2

The connection to the VPN server never drops, it has no error outputs on the console.

I also already tried both UDP and TCP, both show the same behavior. I also did a --mtu-test and OpenVPN gave no error output just:

Code: Select all

Wed Nov 22 20:18:41 2017 Initialization Sequence Completed
Wed Nov 22 20:18:43 2017 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Wed Nov 22 20:21:52 2017 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1525,1525] remote->local=[1522,1522]

I already tried to add mssfix 1200 and tun-mtu 1200 to the config, because I read somewhere this could help, but it didnt for my problem.

Connection output is:

Code: Select all

:screen (openvpn): /usr/sbin/openvpn --config /tmp/ipvanish/fra-a23.ovpn --dev tun0
Wed Nov 22 19:16:29 2017 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Wed Nov 22 19:16:29 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Wed Nov 22 19:16:29 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Wed Nov 22 19:16:29 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Nov 22 19:16:29 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]81.171.58.21:8443
Wed Nov 22 19:16:29 2017 Socket Buffers: R=[87380->87380] S=[16384->16384]
Wed Nov 22 19:16:29 2017 Attempting to establish TCP connection with [AF_INET]81.171.58.21:8443 [nonblock]
Wed Nov 22 19:16:31 2017 TCP connection established with [AF_INET]81.171.58.21:8443
Wed Nov 22 19:16:31 2017 TCP_CLIENT link local: (not bound)
Wed Nov 22 19:16:31 2017 TCP_CLIENT link remote: [AF_INET]81.171.58.21:8443
Wed Nov 22 19:16:31 2017 TLS: Initial packet from [AF_INET]81.171.58.21:8443, sid=cd5b4a02 1639a910
Wed Nov 22 19:16:31 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Nov 22 19:16:31 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Wed Nov 22 19:16:31 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a23.ipvanish.com, emailAddress=support@ipvanish.com
Wed Nov 22 19:16:31 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a23.ipvanish.com, emailAddress=support@ipvanish.com
Wed Nov 22 19:16:31 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
Wed Nov 22 19:16:31 2017 [fra-a23.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.58.21:8443
Wed Nov 22 19:16:32 2017 SENT CONTROL [fra-a23.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Wed Nov 22 19:16:33 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.21.64.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.21.64.2 255.255.254.0,peer-id 0,cipher AES-256-GCM'
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: timers and/or timeouts modified
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Wed Nov 22 19:16:33 2017 Socket Buffers: R=[341760->327680] S=[44800->44800]
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: --ifconfig/up options modified
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: route options modified
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: route-related options modified
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: peer-id set
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: adjusting link_mtu to 1627
Wed Nov 22 19:16:33 2017 OPTIONS IMPORT: data channel crypto options modified
Wed Nov 22 19:16:33 2017 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Nov 22 19:16:33 2017 NCP: overriding user-set keysize with default
Wed Nov 22 19:16:33 2017 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Nov 22 19:16:33 2017 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Nov 22 19:16:33 2017 TUN/TAP device tun0 opened
Wed Nov 22 19:16:33 2017 TUN/TAP TX queue length set to 100
Wed Nov 22 19:16:33 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Nov 22 19:16:33 2017 /sbin/ifconfig tun0 172.21.64.2 netmask 255.255.254.0 mtu 1500 broadcast 172.21.65.255
Wed Nov 22 19:16:33 2017 Initialization Sequence Completed

I actually noticed, and this is really weird, that the connection somehow breaks down, when I do this directly on the router itself:

Code: Select all

ping -s 1480 8.8.8.8 -I tun0

After some short time, the ping command just "stops", does not give any response anymore, and no new connections work anymore on any client. The output literally just randomly stops at some point like:

Code: Select all

1488 bytes from 193.99.144.80: seq=110 ttl=250 time=29.707 ms
1488 bytes from 8.8.8.8: seq=111 ttl=250 time=31.482 ms
1488 bytes from 8.8.8.8: seq=112 ttl=250 time=31.497 ms
1488 bytes from 8.8.8.8: seq=113 ttl=250 time=28.444 ms

Not sure if this is related to the above problem though, maybe this is some ddos protection of the VPN server, though it never loses connection actually, but does not properly route anything anymore, until I restart the connection.

I am literally really frustrated right now and have no idea, how to debug or find out, what could cause the issues. I would welcome any hints or tips. Thank you for reading.

[TinCanTech]

ca /etc/openvpn/keys/ca.ipvanish.com.crt

So the server is ipvanish.com .. ?

[makedir]

ca /etc/openvpn/keys/ca.ipvanish.com.crt

So the server is ipvanish.com .. ?

yes .. ?

[TinCanTech]

Then you need to ask them.

Perhaps they have too many people using their free service and they just drop random clients at will.

[makedir]

Then you need to ask them.

Perhaps they have too many people using their free service and they just drop random clients at will.

Youre too funny. They said they arent aware of any issues. It is not an issue with their servers, and their customer support is also incompetent. They have over 1000 servers and I tried 20, and the problem is happening with every server in what ever country. The usage of the server is 2-6%.

[TinCanTech]

I have tried free VPN providers myself and (IMHO) they are all the same:

They let you use it for free for a while .. then they expect you to pay !

[makedir]

I have tried free VPN providers myself and (IMHO) they are all the same:

They let you use it for free for a while .. then they expect you to pay !

Cool story. I AM paying $12/month for it (since 4 years). They dont have free servers.

[TinCanTech]

I AM paying $12/month for it (since 4 years)

So make them work for your money by supporting you ..

The only thing you can do here is use a higher --verb (say 7) in your config and then capture the timeout.
(which you have not done above)

[makedir]

I AM paying $12/month for it (since 4 years)

So make them work for your money by supporting you ..

The only thing you can do here is use a higher --verb (say 7) in your config and then capture the timeout.
(which you have not done above)

I have tried that and there is no error in the output, just read/write read/write outputs.

[TinCanTech]

So OpenVPN is not the problem .. something else is.