Posted: Sun Oct 22, 2017 22:02 Post subject: Open VPN TLS won't handshake after initial packet - New ISP
Hello,
I recently got a new ISP (Webpass from ATT) and when I first transitioned to it my OpenVPN setup worked just fine for about a day. Now the server receives the initial packet from the client, but the handshake fails.
I tried starting from scratch again, but still nothing. My firewall in DDWRT and windows is off but I still seem unable to connect from outside. The default Linksys profile works on 1194 with the new ISP, otherwise I would have assumed it was a port issue on their end.
client
dev tun
proto udp
remote [My IP] 1194
tun-mtu 1500
resolv-retry infinite
nobind
persist-key
persist-tun
verb 4
float
auth SHA256
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
Firewall
Code:
iptables -t nat -A POSTROUTING -s 172.19.13.0/24 -j MASQUERADE
Server Log
Code:
Sun Oct 22 23:46:04 2017 us=753143 OpenVPN 2.4.3 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Sep 27 2017
Sun Oct 22 23:46:04 2017 us=753160 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.09
Sun Oct 22 23:46:04 2017 us=753991 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:14
Sun Oct 22 23:46:04 2017 us=754204 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Oct 22 23:46:04 2017 us=755047 Diffie-Hellman initialized with 4096 bit key
Sun Oct 22 23:46:04 2017 us=756106 TLS-Auth MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sun Oct 22 23:46:04 2017 us=756445 TUN/TAP device tun2 opened
Sun Oct 22 23:46:04 2017 us=756481 TUN/TAP TX queue length set to 100
Sun Oct 22 23:46:04 2017 us=756510 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Oct 22 23:46:04 2017 us=756555 /sbin/ifconfig tun2 172.19.13.1 netmask 255.255.255.0 mtu 1500 broadcast 172.19.13.255
Sun Oct 22 23:46:04 2017 us=768621 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Sun Oct 22 23:46:04 2017 us=768676 Socket Buffers: R=[180224->180224] S=[180224->180224]
Sun Oct 22 23:46:04 2017 us=768713 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Oct 22 23:46:04 2017 us=768732 UDPv4 link remote: [AF_UNSPEC]
Sun Oct 22 23:46:04 2017 us=768755 MULTI: multi_init called, r=256 v=256
Sun Oct 22 23:46:04 2017 us=768813 IFCONFIG POOL: base=172.19.13.2 size=252, ipv6=0
Sun Oct 22 23:46:04 2017 us=768841 IFCONFIG POOL LIST
Sun Oct 22 23:46:04 2017 us=768909 Initialization Sequence Completed
Sun Oct 22 23:46:36 2017 us=16430 MULTI: multi_create_instance called
Sun Oct 22 23:46:36 2017 us=16528 10.217.64.112:57556 Re-using SSL/TLS context
Sun Oct 22 23:46:36 2017 us=16557 10.217.64.112:57556 LZO compression initializing
Sun Oct 22 23:46:36 2017 us=16746 10.217.64.112:57556 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sun Oct 22 23:46:36 2017 us=16777 10.217.64.112:57556 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Sun Oct 22 23:46:36 2017 us=16853 10.217.64.112:57556 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
Sun Oct 22 23:46:36 2017 us=16874 10.217.64.112:57556 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
RSun Oct 22 23:46:36 2017 us=16933 10.217.64.112:57556 TLS: Initial packet from [AF_INET]10.217.64.112:57556, sid=a781633a 1742b9c7
WWRWWRWRWWRWSun Oct 22 23:47:36 2017 us=365632 10.217.64.112:57556 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Oct 22 23:47:36 2017 us=365668 10.217.64.112:57556 TLS Error: TLS handshake failed
Sun Oct 22 23:47:36 2017 us=365808 10.217.64.112:57556 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Oct 22 23:48:16 2017 us=140623 MULTI: multi_create_instance called
I am no expert on the server front, but on your client settings you could try:
dev tun2
proto udp4
comp-lzo adaptive
I don not think that that will help though
Recent versions have an upgraded SSL and new certificates have to be generated, there is a TLS error so maybe this is the problem?
I will try the settings on the client side, I think dev tun2 is only for the server side though? Assigning the manual identity for the bridge table. Though it now defaults to tun2.
The certificates were generated with v3 of the scripts and were working just fine on the same build, so I really don't think that is the issue. Good thought though, I had that issue when I initially set everything up. Had to track down v3 to generate with and a mandatory level of encryption that I can't remember.
A shot in the dark, but can it be a mtu size error?
I don't think so, I tried changing it to 6000, which the default linksys uses and still nothing. The client connects and I am green but no internet or proper forwarded DNS at work.
egc wrote:
On the client side it probably is: dev tun1
I tried dev tun1 and udp4. No change, the client connects and I am green but no internet or proper forwarded DNS at work.
6000 is an insane value. The maximum Ethernet packet size is 1500. You should try 1400 to make room for the VPN overhead.
I completely agree and I have no idea why it has it set to that. Is there a way to pull the server config through the client logs? Maybe a verb level? It would be super helpful for trying to figure out why one works when the other doesn't.
I will try 1400 and report back.
Edit: Per Yngve Berg, you might be on to something. This is the closest I have gotten. After 5 minutes of loading and then me terminating the connection I was left with this.
Any idea what it may indicate?
Is it running too slowly on the work network that nothing ever happens, but technically working? It seems so strange that this would be the case given the default Linksys profile works perfectly on the same hardware.
