I've got OpenVPN running on an OpenWRT router at the edge of my home network, with the goal being to A) Allow traffic to portions of my LAN, and B) Establish secure connections to the outside world with mobile devices.
The first device I tested on was an Android phone. Initially I had some issues with constant drops because the tls-server option wasn't enabled, but once I turned that on everything began working as expected for it. It still drops, but it is random and seems likely to be due to poor cell service.
On my first testbed box, a laptop I use remotely frequently, I can't get a connection up under Linux or Windows. (Mint/Cinnamon & Win 7 Pro respectively). Initially I thought it might be something specific to Linux, so I swapped over to Windows and spent a while setting that up. Both throw pretty much the same errors, so I've discarded that line of thought.
Here's the Windows config:
client
remote 55.55.55.55 1194
resolv-retry infinite
persist-key
persist-tun
mute-replay-warnings
ca C:\\Users\\redacted\\VPN\\ca.crt
cert C:\\Users\\redacted\\VPN\\redacted.crt
key C:\\Users\\redacted\\VPN\\redacted.key
remote-cert-tls server
verb 5
dev tun
proto udp
log C:\\Users\\redacted\\VPN\\bigandheavyandwood.log
Here's the server config:
config openvpn 'myvpn'
option enabled '1'
option dev 'tun'
option port '1194'
option proto 'udp'
option log '/tmp/itsa.log'
option ca '/etc/openvpn/ca.crt'
option cert '/etc/openvpn/server.crt'
option key '/etc/openvpn/server.key'
option server '10.100.150.0 255.255.255.0'
option dh '/etc/openvpn/dh2048.pem'
option client_to_client '1'
option push 'redirect-gateway def1'
option verb '5'
option tls_server '1'
Here's an exerpt from what I'm seeing on the client while trying to connect:
Sun May 10 11:18:24 2015 us=134069 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 19 2015
Sun May 10 11:18:24 2015 us=134069 library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08
Sun May 10 11:18:24 2015 us=258870 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun May 10 11:18:24 2015 us=258870 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun May 10 11:18:24 2015 us=258870 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Sun May 10 11:18:24 2015 us=258870 Local Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sun May 10 11:18:24 2015 us=258870 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sun May 10 11:18:24 2015 us=258870 Local Options hash (VER=V4): '3514370b'
Sun May 10 11:18:24 2015 us=258870 Expected Remote Options hash (VER=V4): '239669a8'
Sun May 10 11:18:24 2015 us=258870 UDPv4 link local (bound): [undef]
Sun May 10 11:18:24 2015 us=258870 UDPv4 link remote: [AF_INET]55.55.55.55:1194
Sun May 10 11:18:24 2015 us=368070 TLS: Initial packet from [AF_INET]55.55.55.55:1194, sid=784748a2 52d11667
Sun May 10 11:18:25 2015 us=257271 VERIFY OK: depth=1, <REDACTED BUT CORRECT>
Sun May 10 11:18:25 2015 us=257271 Validating certificate key usage
Sun May 10 11:18:25 2015 us=257271 ++ Certificate has key usage 00a0, expects 00a0
Sun May 10 11:18:25 2015 us=257271 VERIFY KU OK
Sun May 10 11:18:25 2015 us=257271 Validating certificate extended key usage
Sun May 10 11:18:25 2015 us=257271 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 10 11:18:25 2015 us=257271 VERIFY EKU OK
Sun May 10 11:18:25 2015 us=257271 VERIFY OK: depth=0, <REDACTED BUT CORRECT>
Sun May 10 11:18:26 2015 us=255673 TLS ERROR: Plaintext buffer too short (1 bytes).
Sun May 10 11:18:26 2015 us=255673 TLS Error: TLS handshake failed
Sun May 10 11:18:26 2015 us=255673 TCP/UDP: Closing socket
Sun May 10 11:18:26 2015 us=255673 SIGUSR1[soft,tls-error] received, process restarting
Sun May 10 11:18:26 2015 us=255673 Restart pause, 2 second(s)
And the server just spits out a lot of:
Sun May 10 18:35:30 2015 us=649730 MULTI: multi_create_instance called
Sun May 10 18:35:30 2015 us=650034 66.66.66.66:61610 Re-using SSL/TLS context
Sun May 10 18:35:30 2015 us=693398 66.66.66.66:61610 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun May 10 18:35:30 2015 us=693612 66.66.66.66:61610 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
RSun May 10 18:35:30 2015 us=693900 66.66.66.66:61610 TLS: Initial packet from [AF_INET]66.66.66.66:61610, sid=fa1f1588 fb5f9d8a
WRRWRWRWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRRRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWR
Sun May 10 18:35:32 2015 us=729712 66.66.66.66:61610 VERIFY OK: depth=1, <REDACTED BUT ACCURATE>
Sun May 10 18:35:32 2015 us=730677 66.66.66.66:61610 VERIFY OK: depth=0, <REDACTED BUT ACCURATE>
WRWRWRWRWRWRWRWRWRWRSun May 10 18:35:33 2015 us=284169 66.66.66.66:61610 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun May 10 18:35:33 2015 us=284370 66.66.66.66:61610 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 10 18:35:33 2015 us=284787 66.66.66.66:61610 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun May 10 18:35:33 2015 us=285106 66.66.66.66:61610 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
WWRSun May 10 18:35:35 2015 us=351499 66.66.66.66:61610 TLS: new session incoming connection from [AF_INET]66.66.66.66:61610
WWRRWRWRWWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRRRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWR
Sun May 10 18:35:36 2015 us=891762 66.66.66.66:61610 VERIFY OK: depth=1, <REDACTED BUT ACCURATE>
Sun May 10 18:35:36 2015 us=892323 66.66.66.66:61610 VERIFY OK: depth=0, <REDACTED BUT ACCURATE>
WRWRWRWRWRWRWRWRWRWRSun May 10 18:35:37 2015 us=372981 66.66.66.66:61610 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun May 10 18:35:37 2015 us=373184 66.66.66.66:61610 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 10 18:35:37 2015 us=373610 66.66.66.66:61610 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun May 10 18:35:37 2015 us=373792 66.66.66.66:61610 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 10 18:35:37 2015 us=374051 66.66.66.66:61610 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Sun May 10 18:35:37 2015 us=396541 66.66.66.66:61610 TLS: tls_multi_process: untrusted session promoted to trusted
WWRSun May 10 18:35:39 2015 us=469746 66.66.66.66:61610 TLS: new session incoming connection from [AF_INET]66.66.66.66:61610
WWRRWRWRWWWWWWWWWWWWWWWWWWWWWWWWWWWSun May 10 18:36:35 2015 us=701310 66.66.66.66:61610 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun May 10 18:36:35 2015 us=701480 66.66.66.66:61610 TLS Error: TLS handshake failed
Sun May 10 18:36:35 2015 us=723835 66.66.66.66:61610 SIGUSR1[soft,tls-error] received, client-instance restarting
The "Plaintext buffer too short" error didn't pull much on a search, mostly stuff about an old DOS exploitable bug that referenced code that had the error in it, and was largely unrelated as far as I can tell.
Based on "TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" in the server output, I can only think that the client is dropping the connection and leaving the server looking, but it's still not clear why this is the case to me.
I'm stumped. Any suggestions?
