Pfsense 2.3.5: OpenVPN Client w/ Certificate & password auth
-
Hello,
I am trying to set up OpenVPN in client mode to a server that expects client certs AND username/password.
This setup works with ipfire as well as my various devices using this client configuration (with myhost.txt containing the username and password):client
remote myhost.whatever.org
ca /var/ipfire/ovpn/ca/cacert.pem
dh /var/ipfire/ovpn/ca/dh2048.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
auth-user-pass /var/ipfire/ovpn/myhost.txt
comp-lzo yes
dev tun
proto tcp
nobind
auth-nocache
script-security 2
persist-key
persist-tunIn pfsense however, this does not work. Config:
server mode p2p ssl/tls
protocol tcp
device mode tun
interface wan
server myhost.whatever.org
server port 1194
indefinitively resolve server checked
tls enable auth of tls packets unchecked
peer ca present and imported
valid client certificate
encryption bf-cbc
auth sha1 (160)
no hardware crypto
disable ipv6 checkedI tried to set authentication using the available username/password-fields as well as specifying auth-user-pass. Result is the same:
pfsense tries to open the connection, both certificates get checked (can be seen in both server and client log), server then reports "SIGUSR1[soft,connection-reset] received, client-instance restarting"
On the client-side, I getDec 3 21:42:53 openvpn 51387 OpenSSL: error:140D1044:SSL routines:TLS1_CHANGE
_CIPHER_STATE:internal error
Dec 3 21:42:53 openvpn 51387 TLS_ERROR: BIO read tls_read_plaintext error
Dec 3 21:42:53 openvpn 51387 TLS Error: TLS object -> incoming plaintext read
error
Dec 3 21:42:53 openvpn 51387 TLS Error: TLS handshake failed
Dec 3 21:42:53 openvpn 51387 Fatal TLS error (check_tls_errors_co), restartin
g
Dec 3 21:42:53 openvpn 51387 SIGUSR1[soft,tls-error] received, process restar
tingA login with the credentials provided is never attempted.
Excessive googling did not yield any usable results…what am I missing ?
Thanks in advance for any hints.
Regards
Markus -
I did some more tests.
-
To avoid any shenanigans caused by the gui, I set up some config files like the ones I used in the already working clients, started openvpn manually and…the problem remains.
-
I set up a test OpenVPN server with a fresh debian install, certificates by easyrsa (2048 bits), config like my original server config but without username/password (just plain certificate auth). Problem still remains.
Are there maybe some limitations as to which ciphers / auth are actually supported by the openssl version provided that are not reflected in the gui settings ?
Is there anybody out there being able to help or give at least a clue ? :(
-
-
Your example ipfire config doesn't have TLS auth enabled or a TLS key specified. Uncheck the option for TLS auth on the pfSense GUI.
-
Well, the use of a shared key is not intended, so it still IS unchecked. Just a client certificate and user/pw shall be used. I don't think that this should be the problem since it definitively works with other OpenVPN clients (even on frikkin iOS).
Any GUI settings should not matter since for testing I tried to run the exact configuration that runs on other clients from command line (without any of the gui stuff, config.xml or whatever, just a plain config file, see the first part of my posting, only the paths have changed) and it did not work.
Was OpenVPN/OpenSSL on pfsense compiled to require TLS keys/TLS auth ? -
Ah, I misread your first post. I thought it said you had that checked. But the errors in your log also made me lean that way.
Trying to run OpenVPN on your own at the CLI is doomed to fail. Make it work using the GUI.
There isn't anything special about how OpenVPN is compiled on pfSense. It doesn't require anything specific compared to other OpenVPN implementations. I run clients that use SSL/TLS and client auth all the time, no problems at all.
Are the log messages you see always the same? Can you see any logs from the server side?
-
Using OpenVPN on pfsense in a standalone manner makes no sense, you are right about that. To eliminate influences from the gui it should work as a test anyways, provided that an otherwise functional config is used…well it didn't which brings me to the impression that there may be some fundamental problem with the way OpenVPN or OpenSSL are implemented on pfsense 2.3.5.
Yes, the log messages on pfsense are always the same as provided, regardless of whether I am using the GUI config or my manual test.
On the server side there is not much to be seen other than (I used verb 6):Tue Dec 5 17:28:58 2017 188.174.184.143:32018 VERIFY OK: depth=1, O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority, emailAddress=support@cacert.org
Tue Dec 5 17:28:58 2017 188.174.184.143:32018 VERIFY OK: depth=0, CN=CAcert WoT User, emailAddress=what@ever.com
Tue Dec 5 17:28:58 2017 188.174.184.143:32018 Connection reset, restarting [0]
Tue Dec 5 17:28:58 2017 188.174.184.143:32018 SIGUSR1[soft,connection-reset] received, client-instance restartingOn the client (pfsense) side, I do get the following:
Dec 5 17:34:42 pfSense openvpn[27012]: LZO compression initialized
Dec 5 17:34:42 pfSense openvpn[27012]: Control Channel MTU parms [ L:1560 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Dec 5 17:34:42 pfSense openvpn[27012]: Socket Buffers: R=[65228->65228] S=[65228->65228]
Dec 5 17:34:42 pfSense openvpn[27012]: Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:143 ET:0 EL:3 AF:3/1 ]
Dec 5 17:34:42 pfSense openvpn[27012]: Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Dec 5 17:34:42 pfSense openvpn[27012]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Dec 5 17:34:42 pfSense openvpn[27012]: Local Options hash (VER=V4): '958c5492'
Dec 5 17:34:42 pfSense openvpn[27012]: Expected Remote Options hash (VER=V4): '79ef4284'
Dec 5 17:34:42 pfSense openvpn[27012]: Attempting to establish TCP connection with [AF_INET]54.93.66.226:1194 [nonblock]
Dec 5 17:34:43 pfSense openvpn[27012]: TCP connection established with [AF_INET]54.93.66.226:1194
Dec 5 17:34:43 pfSense openvpn[27012]: TCPv4_CLIENT link local (bound): [AF_INET]10.1.1.248
Dec 5 17:34:43 pfSense openvpn[27012]: TCPv4_CLIENT link remote: [AF_INET]54.93.66.226:1194
pid=0 DATA len=0
Dec 5 17:34:43 pfSense openvpn[27012]: TCPv4_CLIENT READ [26] from [AF_INET]54.93.66.226:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Dec 5 17:34:43 pfSense openvpn[27012]: TLS: Initial packet from [AF_INET]54.93.66.226:1194, sid=3f9ad645 9c022684
Dec 5 17:34:43 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 0 ]
pid=1 DATA len=249
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT READ [126] from [AF_INET]54.93.66.226:1194: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 1 ]
pid=2 DATA len=100
pid=3 DATA len=100
pid=4 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 2 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [26] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 3 4 ]
pid=5 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 5 ]
pid=6 DATA len=100
pid=7 DATA len=100
pid=8 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 6 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [26] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 7 8 ]
pid=9 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 9 ]
pid=10 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 10 ]
pid=11 DATA len=100
pid=12 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 11 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 12 ]
pid=13 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 13 ]
pid=14 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 14 ]
pid=15 DATA len=100
pid=16 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 15 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 16 ]
pid=17 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 17 ]
pid=18 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 18 ]
pid=19 DATA len=100
pid=20 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 19 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 20 ]
pid=21 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 21 ]
pid=22 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 22 ]
pid=23 DATA len=100
pid=24 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 23 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 24 ]
pid=25 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 25 ]
pid=26 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 26 ]
pid=27 DATA len=100
pid=28 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 27 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 28 ]
pid=29 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 29 ]
pid=30 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 30 ]
pid=31 DATA len=100
pid=32 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 31 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 32 ]
pid=33 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: VERIFY OK: depth=1, O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority, emailAddress=support@cacert.org
Dec 5 17:34:44 pfSense openvpn[27012]: VERIFY OK: depth=0, CN=myhost.org
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 33 ]
pid=34 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 34 ]
pid=35 DATA len=100
pid=36 DATA len=100
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 35 ]
Dec 5 17:34:44 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 36 ]
pid=37 DATA len=100
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 37 ]
pid=38 DATA len=100
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 38 ]
pid=39 DATA len=100
pid=40 DATA len=100
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 39 ]
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 40 ]
pid=41 DATA len=100
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 41 ]
pid=42 DATA len=100
Dec 5 17:34:45 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [22] to [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 42 ]
pid=43 DATA len=84
Dec 5 17:34:46 pfSense openvpn[27012]: TCPv4_CLIENT WRITE [1196] to [AF_INET]54.93.66.226:1194: P_CONTROL_V1 kid=0 [ 43 ] pid=2 DATA len=1170
pid=3 DATA len=1170
pid=4 DATA len=1170
pid=5 DATA len=361
Dec 5 17:34:46 pfSense openvpn[27012]: TCPv4_CLIENT READ [22] from [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 2 ]
Dec 5 17:34:46 pfSense openvpn[27012]: TCPv4_CLIENT READ [22] from [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 3 ]
Dec 5 17:34:46 pfSense openvpn[27012]: TCPv4_CLIENT READ [22] from [AF_INET]54.93.66.226:1194: P_ACK_V1 kid=0 [ 4 ]
Dec 5 17:34:46 pfSense openvpn[27012]: TCPv4_CLIENT READ [85] from [AF_INET]54.93.66.226:1194: P_CONTROL_V1 kid=0 [ 5 ] pid=44 DATA len=59
Dec 5 17:34:46 pfSense openvpn[27012]: OpenSSL: error:140D1044:SSL routines:TLS1_CHANGE_CIPHER_STATE:internal error
Dec 5 17:34:46 pfSense openvpn[27012]: TLS_ERROR: BIO read tls_read_plaintext error
Dec 5 17:34:46 pfSense openvpn[27012]: TLS Error: TLS object -> incoming plaintext read error
Dec 5 17:34:46 pfSense openvpn[27012]: TLS Error: TLS handshake failed
Dec 5 17:34:46 pfSense openvpn[27012]: Fatal TLS error (check_tls_errors_co), restarting
Dec 5 17:34:46 pfSense openvpn[27012]: TCP/UDP: Closing socket
Dec 5 17:34:46 pfSense openvpn[27012]: SIGUSR1[soft,tls-error] received, process restartingThe entry that makes me wonder -although I don't know exactly how that effects the outcome- is the local options/remote options part. I don't see any acknowledgement here.
-
I do see one more thing there that doesn't line up.
From your example config above:
encryption bf-cbc
And then from your log output:
Dec 5 17:34:42 pfSense openvpn[27012]: Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Dec 5 17:34:42 pfSense openvpn[27012]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'It shows you using AES-256-CBC locally, not BF-CBC.
-
You are right, this is a fragment of testing. However, the result stays the same. The server has both ciphers declared to be used. If -with a working client which has no preference set- I do "undeclare" the default cipher, the auth still succeeds but after a few seconds the connection is dropped complaining a difference of ciphers between client and server. I do think the problem is to be found earlier, within the authentication. Maybe the default auth cipher for OpenVPN (SHA1 160Bit) is disallowed by now without that change being reflected within the gui settings ?
-
SHA1 is authentication, not encryption, and SHA1 is the default authentication method for OpenVPN. If you don't see an "auth xxxx" line in the config then it's using SHA1.
Is the server running OpenVPN 2.4? Is is possible there is an option enabled there which is specific to OpenVPN 2.4 and won't allow OpenVPN 2.3 to work? If that is the case, the server may need adjusting or you may need to update the client to pfSense 2.4 which includes OpenVPN 2.4.
-
Well, the server is 2.3.4. I used a dummy endpoint for tests with 2.3.7 with the same result, so this is a non-issue. Yes, SHA1 is an auth scheme, not an encryption scheme. What makes me wonder is that the dummy endpoint as well as the actual server, when having no auth defined on both sides (hence SHA1 is to be used), the auth works -as expected- but when there' s a config error in encryption or compression, connection breaks -as expected- with an appropriate error message.
In the current config/setup however, no matter how erroneous my encryption config or my compression may be, it doesn't even get to the point of complaining the wrong config. This makes me think that maybe there is something wrong with the auth mechanisms to be used by default by the current pfsense version