@pirretub when I do a speedtest (speedtest http://speedtest.net/) and have htop opened on the router, cpu (openvpn process) will cap at 100% with a bandwidth of 70mbit/s, regardless if cryptodev used or not). I just had 30 minutes rock stable connections on my laptop, and then, puff... a few minutes ago, all timeouts again happening opening new tabs on chrome. VPN connection is open, no issues. This doesnt seem to be a problem of OpenVPN but with the router (nat, iptables, firewall, whatever).
:screen (openvpn): /usr/sbin/openvpn --config /tmp/ipvanish/fra-a40.ovpn --dev tun0
Sun Nov 26 16:10:16 2017 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sun Nov 26 16:10:16 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Nov 26 16:10:16 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Sun Nov 26 16:10:16 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Nov 26 16:10:17 2017 Initializing OpenSSL support for engine 'cryptodev'
Sun Nov 26 16:10:17 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Nov 26 16:10:17 2017 UDP link local: (not bound)
Sun Nov 26 16:10:17 2017 UDP link remote: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 TLS: Initial packet from [AF_INET]81.171.85.30:1194, sid=88894593 b70725ff
Sun Nov 26 16:10:17 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 16:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 16:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 16:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 16:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
Sun Nov 26 16:10:17 2017 [fra-a40.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:18 2017 SENT CONTROL [fra-a40.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Sun Nov 26 16:10:18 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.32.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.21.32.109 255.255.254.0,peer-id 6'
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: explicit notify parm(s) modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun Nov 26 16:10:18 2017 Socket Buffers: R=[163840->327680] S=[163840->163840]
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route-related options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: peer-id set
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Nov 26 16:10:18 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 TUN/TAP device tun0 opened
Sun Nov 26 16:10:18 2017 TUN/TAP TX queue length set to 100
Sun Nov 26 16:10:18 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Nov 26 16:10:18 2017 /sbin/ifconfig tun0 172.21.32.109 netmask 255.255.254.0 mtu 1500 broadcast 172.21.33.255
Sun Nov 26 16:10:18 2017 Initialization Sequence Completed
Sun Nov 26 17:10:17 2017 TLS: soft reset sec=0 bytes=376258769/-1 pkts=395962/0
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 17:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 17:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 17:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 17:10:17 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
You can see, nothing bad happens with the VPN connection. Theres just the 60mins TLS reset, all working fine.
Client config:
client
dev tun
proto udp
remote 81.171.85.30 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 fra-a40.ipvanish.com name
script-security 2
route-noexec
route-up /etc/openvpn/up/route-up.sh
down /etc/openvpn/down/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
I actually noticed this behavior in the logs of dnsmasq:
Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses
Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.warn odhcpd[1500]: DHCPV6 REQUEST IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 3 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses
It seems to restart iself always a new client/pc boots or connects to wifi...why? It could be that whenever this happens it somehow breaks everything. This wasnt the case in my old OpenWRT build. Can I deactivate this somehow?
(Last edited by makedir on 26 Nov 2017, 18:12)