[SOLVED] can't establish OpenVPN - college network connection

deltalord · Mar 7, 2013, 9:40 PM

Hi, I'm not able to establish the connection between pfSense and my college network although I have all the CA and cert files, but I have trouble with the OpenVPN Client service. With the Windows OpenVPN Client however a connection can be established. But with Windows, while the connection is starting up, a username and password field pops up and I have to authenticate myself (which I don't think makes sense due to the fact that I have the correct CA and cert files, but anyhow, that's how it goes around here).

Below you see either the pfSense logfile and two screenshots of my setup.

I hope anybody can help since I want to get rid of windows and rid of the "dial up method" I currently have to use in order to connect to the university network.

Thanks in advance!

connection.ovpn:


client
proto udp
auth RSA-SHA1
script-security 2
remote 10.205.1.12 1196
link-mtu 1541
auth-user-pass
tls-client
tls-remote /C=DE/ST=./*******************
ns-cert-type server
cipher BF-CBC
route-delay 1 30
persist-key
persist-tun
nobind
# comp-lzo
verb 3

ca xxxx.crt
cert yyyy.crt
key yyyy.key
tls-auth yyyy_ta.key 1

pfsense openvpn log:

Mar 6 12:31:18 	openvpn[58306]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 6 2012
Mar 6 12:31:18 	openvpn[58306]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Mar 6 12:31:18 	openvpn[58306]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 6 12:31:18 	openvpn[58306]: Control Channel Authentication: using '/var/etc/openvpn/client1.tls-auth' as a OpenVPN static key file
Mar 6 12:31:18 	openvpn[58306]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 6 12:31:18 	openvpn[58306]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 6 12:31:18 	openvpn[58306]: LZO compression initialized
Mar 6 12:31:18 	openvpn[58306]: Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Mar 6 12:31:18 	openvpn[58306]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Mar 6 12:31:18 	openvpn[58306]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 6 12:31:18 	openvpn[58306]: Local Options hash (VER=V4): '504e774e'
Mar 6 12:31:18 	openvpn[58306]: Expected Remote Options hash (VER=V4): '14168603'
Mar 6 12:31:18 	openvpn[58618]: UDPv4 link local (bound): [AF_INET]10.238.111.197
Mar 6 12:31:18 	openvpn[58618]: UDPv4 link remote: [AF_INET]10.205.1.12:1196
Mar 6 12:31:18 	openvpn[58618]: TLS: Initial packet from [AF_INET]10.205.1.12:1196, sid=373ab601 a20d3450
Mar 6 12:31:19 	openvpn[58618]: VERIFY OK: depth=1, /C=DE/L=*******************
Mar 6 12:31:19 	openvpn[58618]: VERIFY OK: nsCertType=SERVER
Mar 6 12:31:19 	openvpn[58618]: VERIFY OK: depth=0, /C=DE/ST=./L=*******************
Mar 6 12:32:18 	openvpn[58618]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 6 12:32:18 	openvpn[58618]: TLS Error: TLS handshake failed
Mar 6 12:32:18 	openvpn[58618]: TCP/UDP: Closing socket
Mar 6 12:32:18 	openvpn[58618]: SIGUSR1[soft,tls-error] received, process restarting
Mar 6 12:32:18 	openvpn[58618]: Restart pause, 2 second(s)
Mar 6 12:32:20 	openvpn[58618]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 6 12:32:20 	openvpn[58618]: Re-using SSL/TLS context
Mar 6 12:32:20 	openvpn[58618]: LZO compression initialized
Mar 6 12:32:20 	openvpn[58618]: Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Mar 6 12:32:20 	openvpn[58618]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Mar 6 12:32:20 	openvpn[58618]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 6 12:32:20 	openvpn[58618]: Local Options hash (VER=V4): '504e774e'
Mar 6 12:32:20 	openvpn[58618]: Expected Remote Options hash (VER=V4): '14168603'
Mar 6 12:32:20 	openvpn[58618]: UDPv4 link local (bound): [AF_INET]10.238.111.197
Mar 6 12:32:20 	openvpn[58618]: UDPv4 link remote: [AF_INET]10.205.1.12:1196
Mar 6 12:32:20 	openvpn[58618]: TLS: Initial packet from [AF_INET]10.205.1.12:1196, sid=ecd22a39 a63f9b19
Mar 6 12:32:20 	openvpn[58618]: VERIFY OK: depth=1, /C=DE/L=*******************
Mar 6 12:32:20 	openvpn[58618]: VERIFY OK: nsCertType=SERVER
Mar 6 12:32:20 	openvpn[58618]: VERIFY OK: depth=0, /C=DE/ST=./L=*******************

Basically the log ends with "TLS handshake failed" where on the other hand the windows client succeeds and adds the routes.

Screenshots:

Nadrek · Mar 8, 2013, 5:30 AM

First, I've never used


auth-user-pass

when using certificates - that's for username and password authentication, which you don't want.

Second, I've only used pfSense as an OpenVPN server; can you help me understand where your connection.ovpn file is stored, and how it relates to the pfSense configuration?

Your connection.ovpn lists


auth RSA-SHA1

but the pfSense screen shots don't show that in the Advanced box. Also, the connection.ovpn enables compression, but the pfSense screen has compression disabled. If these two are supposed to match, go through them line by line and make sure they're as identical as possible.

deltalord · Mar 8, 2013, 1:08 PM

Thanks for your fast reply.

Adjusting the config according to your hints resulted in a different logfile, but still no connection. Basically all that changed is that I don't receive the "TLS handshake failed" message.

Mar 8 06:20:07 	openvpn[17870]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 6 2012
Mar 8 06:20:07 	openvpn[17870]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Mar 8 06:20:07 	openvpn[17870]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 8 06:20:07 	openvpn[17870]: Control Channel Authentication: using '/var/etc/openvpn/client1.tls-auth' as a OpenVPN static key file
Mar 8 06:20:07 	openvpn[17870]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 8 06:20:07 	openvpn[17870]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 8 06:20:07 	openvpn[17870]: LZO compression initialized
Mar 8 06:20:07 	openvpn[17870]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1499)
Mar 8 06:20:07 	openvpn[17870]: Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Mar 8 06:20:07 	openvpn[17870]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Mar 8 06:20:07 	openvpn[17870]: Data Channel MTU parms [ L:1541 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 8 06:20:07 	openvpn[17870]: Local Options hash (VER=V4): '76f6b8ba'
Mar 8 06:20:07 	openvpn[17870]: Expected Remote Options hash (VER=V4): '5e7afe65'
Mar 8 06:20:07 	openvpn[18101]: UDPv4 link local (bound): [AF_INET]10.238.111.197
Mar 8 06:20:07 	openvpn[18101]: UDPv4 link remote: [AF_INET]10.205.1.12:1196
Mar 8 06:20:07 	openvpn[18101]: TLS: Initial packet from [AF_INET]10.205.1.12:1196, sid=fd85fb88 07ebf024
Mar 8 06:20:07 	openvpn[18101]: VERIFY OK: depth=1, /C=DE/L=*******************
Mar 8 06:20:07 	openvpn[18101]: VERIFY OK: nsCertType=SERVER
Mar 8 06:20:07 	openvpn[18101]: VERIFY OK: depth=0, /C=DE/ST=./L=*******************
Mar 8 06:21:07 	openvpn[18101]: [139.90.9.1] Inactivity timeout (--ping-restart), restarting
Mar 8 06:21:07 	openvpn[18101]: TCP/UDP: Closing socket
Mar 8 06:21:07 	openvpn[18101]: SIGUSR1[soft,ping-restart] received, process restarting
Mar 8 06:21:07 	openvpn[18101]: Restart pause, 2 second(s)
Mar 8 06:21:09 	openvpn[18101]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 8 06:21:09 	openvpn[18101]: Re-using SSL/TLS context
Mar 8 06:21:09 	openvpn[18101]: LZO compression initialized
Mar 8 06:21:09 	openvpn[18101]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1499)
Mar 8 06:21:09 	openvpn[18101]: Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Mar 8 06:21:09 	openvpn[18101]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Mar 8 06:21:09 	openvpn[18101]: Data Channel MTU parms [ L:1541 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 8 06:21:09 	openvpn[18101]: Local Options hash (VER=V4): '76f6b8ba'
Mar 8 06:21:09 	openvpn[18101]: Expected Remote Options hash (VER=V4): '5e7afe65'
Mar 8 06:21:09 	openvpn[18101]: UDPv4 link local (bound): [AF_INET]10.238.111.197
Mar 8 06:21:09 	openvpn[18101]: UDPv4 link remote: [AF_INET]10.205.1.12:1196
Mar 8 06:21:09 	openvpn[18101]: TLS: Initial packet from [AF_INET]10.205.1.12:1196, sid=e6c41a56 3ea1c8b3
Mar 8 06:21:09 	openvpn[18101]: VERIFY OK: depth=1, /C=DE/L=*******************
Mar 8 06:21:09 	openvpn[18101]: VERIFY OK: nsCertType=SERVER
Mar 8 06:21:09 	openvpn[18101]: VERIFY OK: depth=0, /C=DE/ST=./L=*******************

phil.davis · Mar 8, 2013, 3:10 PM

If the college has a server that is doing SSL/TLS + User Auth (like a pfSense OPenVPN Road Warrior server would usually do) then the college server will need you to have the college CA (presumably self-signed - you need it so that you can trust it) and a client certificate for you (issued by the college CA - so the college server will recognise you), but just having these is not good enough if the college server also requires User Auth (I guess they don't want anyone who steals your laptop to be able to just connect the VPN because the laptop has CA+Cert in it).
I think that the client also needs to pass your username/password. And I don't think pfSense has anywhere for you to enter that in the client config. And in any case, if it did, I'm sure the college would not like that being stored in a private router setup that would auto-connect the VPN, because then anyone behind your private router can access the college network using the VPN authorisation given to you.
Others who know more about this please comment - but I suspect there is a "no-go" here because the connection really does need a human to give the user auth each time it connects.

johnpoz · Mar 8, 2013, 7:18 PM

phil makes some good points about security behind also requiring userauth. And valid points about connecting your router to their network vs just one machine, etc.

But I do believe you can get pfsense to send userauth via example here http://doc.pfsense.org/Create-OpenVPN-client-to-TUVPNcom.pdf

In a nutshell you create a file with the username and password in it, and then use auth-user-pass option in advanced options to point to the file.

deltalord · Mar 9, 2013, 9:11 PM

@johnpoz:

In a nutshell you create a file with the username and password in it, and then use auth-user-pass option in advanced options to point to the file.

Not the most elegant way of storing critical information, but connection established. Thanks johnpoz for your help.

@ board admins: problem solved!

How?
First off I was blind, missed that comp-lzo was commented out. Second, I applied the user-auth workaround mentioned above.

Nadrek · Mar 9, 2013, 9:45 PM

Excellent - I'm glad that's working for you!

Would you be willing to provide one last screenshot of the working configuration?

deltalord · Mar 10, 2013, 8:59 PM

Gladly: