[SOLVED] TLS help

browley

I am having issues getting TLS working. Initially I had an Bridged + OpenLDAP setup. I got that working after a bit of a rough patch with some networking issues. Here are my configs
Server config:

port 1194
proto tcp
dev tap0
mode server
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.101.14 255.255.255.0 192.168.101.223 192.168.101.253
push "dhcp-option DNS 192.168.101.17"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
duplicate-cn
keepalive 10 60
tls-auth ta.key 0 
cipher BF-CBC        
comp-lzo
user nobody
group nobody
persist-key
persist-tun
log         /var/log/openvpn.log
verb 5
plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so "/etc/openvpn/auth/ldap.conf"
client-cert-not-required

Client config:

client
dev tap0
proto tcp
remote 38..xx.yy.zzz
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
#cert client.crt
#key client.key
#ns-cert-type server
tls-auth ta.key 1
comp-lzo
cipher BF-CBC 
verb 6
auth-user-pass

I double checked that both ta.keys and ca.crt on the server/client have the same MD5 so they're definitely the same files. Here's what happens when I try and connect.

Server:

Mon Jun 25 14:12:25 2012 us=571309 146.xx.yy.zz:50467 TLS: Initial packet from 146.115.xx.yy:50467, sid=e23feba0 7a0ff0d1
Mon Jun 25 14:12:25 2012 us=571335 146.xx.yy.zz:50467 Authenticate/Decrypt packet error: packet HMAC authentication failed
Mon Jun 25 14:12:25 2012 us=571354 146.xx.yy.zz:50467 TLS Error: incoming packet authentication failed from 146.115.xx.yy:50467
Mon Jun 25 14:12:25 2012 us=571515 146.xx.yy.zz:50467 Fatal TLS error (check_tls_errors_co), restarting

Client:

Wed Jun 27 08:29:21 2012 us=704000 Control Channel Authentication: tls-auth using INLINE static key file
Wed Jun 27 08:29:21 2012 us=704000 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 27 08:29:21 2012 us=704000 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 27 08:29:21 2012 us=704000 LZO compression initialized
Wed Jun 27 08:29:21 2012 us=704000 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
Wed Jun 27 08:29:21 2012 us=704000 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Jun 27 08:29:21 2012 us=704000 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Jun 27 08:29:21 2012 us=704000 Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Wed Jun 27 08:29:21 2012 us=704000 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Wed Jun 27 08:29:21 2012 us=704000 Local Options hash (VER=V4): '2259a6dc'
Wed Jun 27 08:29:21 2012 us=704000 Expected Remote Options hash (VER=V4): '692eb0f5'
Wed Jun 27 08:29:21 2012 us=704000 Attempting to establish TCP connection with 38.xx.yy.zz:1194
Wed Jun 27 08:29:21 2012 us=704000 MANAGEMENT: >STATE:1340800161,TCP_CONNECT,,,
Wed Jun 27 08:29:21 2012 us=736000 TCP connection established with 38.xx.yy.zz:1194
Wed Jun 27 08:29:21 2012 us=736000 TCPv4_CLIENT link local: [undef]
Wed Jun 27 08:29:21 2012 us=736000 TCPv4_CLIENT link remote: 38.xx.yy.zz:1194
Wed Jun 27 08:29:21 2012 us=736000 MANAGEMENT: >STATE:1340800161,WAIT,,,
Wed Jun 27 08:29:21 2012 us=736000 TCPv4_CLIENT WRITE [42] to 38.xx.yy.zz:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Wed Jun 27 08:29:21 2012 us=751000 Connection reset, restarting [0]
Wed Jun 27 08:29:21 2012 us=751000 TCP/UDP: Closing socket

From Googling it would seem that either the keys are mismatched, there is network corruption, or the port numbers are messed up. I've also tried the configs without ciphers but the problem persists. Any thoughts? Maybe I should ask a more simple question: can I not use a combination of the LDAP auth with TLS?

janjust

Add 'verb 5' or higher to both sides, then restart openvpn on both ends. openvpn should now report the keys it is using for HMAC signing, similar to

Thu Jun 28 16:10:52 2012 us=30928 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jun 28 16:10:52 2012 us=30998 Outgoing Control Channel Authentication: HMAC KEY: 1c748f91 3c45e6dd f11f6b6d cdb2f8b6 ca94eea8
Thu Jun 28 16:10:52 2012 us=31051 Outgoing Control Channel Authentication: HMAC size=20 block_size=64
Thu Jun 28 16:10:52 2012 us=31115 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jun 28 16:10:52 2012 us=31182 Incoming Control Channel Authentication: HMAC KEY: 51cc24c0 bc38b34c 70d1684a ea2a5a2e 396f3e2c
Thu Jun 28 16:10:52 2012 us=31244 Incoming Control Channel Authentication: HMAC size=20 block_size=64

check that the incoming key on the server matches the outgoing key on the client and vice versa.

browley

Well, your sentiment was spot on. Here's what I found:

Server:

Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication: HMAC KEY: a92c98f7 70350161 217d68c0 6ef244b6 770f175c

Client:

Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication: HMAC KEY: e7ecf4a2 c827b184 789e3ed8 70c3044c 3bd5620f

So that would mean a key mismatch, right? But I've double checked the md5's and even opened the file and looked by hand: they're the same. Does that mean that there's something else happening in network transit to throw off the hashes? Is the SHA1 hash mechanism broken somewhere? I have no idea at this point. Thanks again for any pointers.

janjust

check the md5 sums of the ta.key file; specify full path names to the keys and start OpenVPN again and check the keys.

Also, check the versions/builds of openvpn and the underlying openssl libs - esp on embedded platforms (dd-wrt) this sometimes is an issue.

browley

Here's the MD5's compared:

Server

[root@dev openvpn]# md5sum /etc/openvpn/ta.key 
2fecae31d75abc8fb40d8f5bae00bebe  /etc/openvpn/ta.key

client

C:\Windows\system32>c:\Windows\System32\fciv.exe "c:\Program Files (x86)\OpenVPN
Technologies\OpenVPN Client\prism\ta.key"
//
// File Checksum Integrity Verifier version 2.05.
//
2fecae31d75abc8fb40d8f5bae00bebe c:\program files (x86)\openvpn technologies\openvpn client\prism\ta.key

Here's my OpenVPN/OpenSSL version on CentOS 5.8:

openvpn.x86_64     2.2.2-1.el5.rf        installed
openssl.x86_64      0.9.8e-22.el5_8.4  installed

So I updated the client to include all paths then something funny happened:

Options error: Unrecognized option or missing parameter(s) in stdin:9: C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\prism\ca.crt (2.1.1oOAS) Use --help for more information.

Here's the new client config with full paths. I made sure there were no extra spaces/tabs/white space in the file in general.

client
dev tap0
proto tcp
remote 38.xx.yy.zz
resolv-retry infinite
nobind
persist-key
persist-tun
"C:\\Program Files (x86)\\OpenVPN Technologies\\OpenVPN Client\\prism\\ca.crt"
#cert browley.crt
#key browley.key
"C:\\Program Files (x86)\\OpenVPN Technologies\\OpenVPN Client\\prism\\tls-auth\\ta.key"
cipher BF-CBC
comp-lzo
verb 9
auth-user-pass

I'm starting to think there is a descrepancy with the way the client is hashing and the server is hashing.

janjust

ah you're using the commercial version of the client against the community version of the server... please try the community version of the client as well; for windows you can download it here:
http://swupdate.openvpn.org/community/releases/openvpn-2.2.2-install.exe

browley

Well... there needs to be a smiley for slapping oneself in the face.

So I installed it, fired it up, connected no issues on the first shot. DNS is working, which is awesome.

The one thing that seems problematic was windows remote desktop. There was a lot of trouble connecting. At first I though it was my Linux remote desktop client but even the windows one has trouble. Without TLS, I was able to connect fine. Any ideas? Could it be due to the TLS overhead?

Oh, and btw janjust, you flippin' rock for helping me. Thanks.

janjust

RDP does not work but ping does? how about file transfers? or "large" ping packets (on windows, use 'ping -f -l NNNN <IP>'

if those also do not work, then try adding 'fragment 1300' to both client and server configs.

browley

I'm going to chalk this up to my horrible upload rate with my home connection. RDP has trouble going from the server side lan (very high bandwidth) to my home connection (low upload bandwidth). I actually tried going the other way and was able to RDP from my home connection through the VPN connection. This is solved. Thanks again for the help.