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-tun

    In 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 checked

    I 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 get

    Dec 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
    ting

    A 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 ? :(


  • Rebel Alliance Developer Netgate

    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 ?


  • Rebel Alliance Developer Netgate

    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 restarting

    On 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


    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 ]

    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 ]



    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 ]

    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 ]



    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]


    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 ]

    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 ]

    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 ]

    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



    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 restarting

    The 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.


  • Rebel Alliance Developer Netgate

    I do see one more thing there that doesn't line up.

    From your example config above:

    @rumbero71:

    encryption bf-cbc

    And then from your log output:

    @rumbero71:

    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 ?


  • Rebel Alliance Developer Netgate

    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


Log in to reply