PFSense and OpenVPN: Linux client issues



  • So at $work we use pF version 2.3.3 with OpenVPN 2.3.14, client OpenVPN versions 2.4 on both Windows and Fedora.  My issue currently is that Windows clients are perfect.  Windows 10 works amazingly well with this client and config.  My Fedora client on the other hand absolutely refuses to connect.  I even created a much less secure server in pF to test with that it still will not form a connection.  Below is the client config:

    Client config:
    dev tun
    persist-tun
    persist-key
    cipher CAMELLIA-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote 72.174.xx.xx 34448 udp
    ns-cert-type server
    comp-lzo yes

    <ca>–---BEGIN CERTIFICATE-----

    -----END CERTIFICATE-----</ca>
    <cert>-----BEGIN CERTIFICATE-----

    -----END CERTIFICATE-----</cert>
    <key>-----BEGIN PRIVATE KEY-----

    -----END PRIVATE KEY-----</key>

    Server config:

    [2.3.3-RELEASE][root@gntc-fw-1.domain.com]/var/etc/openvpn: cat server2.conf
    dev ovpns2
    verb 4
    dev-type tun
    tun-ipv6
    dev-node /dev/tun2
    writepid /var/run/openvpn_server2.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher CAMELLIA-256-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 72.174.xx.xx
    tls-server
    server 10.0.40.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server2
    lport 34448
    management /var/etc/openvpn/server2.sock unix
    max-clients 10
    push "route 10.0.20.0 255.255.255.0"
    push "dhcp-option DNS 10.0.20.19"
    push "dhcp-option DNS 10.0.20.20"
    push "dhcp-option NTP 198.206.133.14"
    push "dhcp-option NTP 96.126.100.203"
    ca /var/etc/openvpn/server2.ca
    cert /var/etc/openvpn/server2.cert
    key /var/etc/openvpn/server2.key
    dh /etc/dh-parameters.2048
    comp-lzo yes
    persist-remote-ip
    float
    topology subnet

    Connection attempts are left with this:

    "TLS Error: Unroutable control packet received"

    I sincerely hope someone here might be able to help as this is literally the last roadblock to me switching to linux at work completely.

    Thanks all



  • My kingdom for an OpenVPN Guru!!!

    Or at least a beer of your choosing  ;)



  • Post the overall log section of connection attempt from server and client, please.



  • I had plans on doing this sooner.. but work got in the way.

    Tue Mar  7 23:40:06 2017 us=966790 library versions: OpenSSL 1.0.2k-fips  26 Jan 2017, LZO 2.08
    Enter Auth Username: bhart
    Enter Auth Password: ************************
    Tue Mar  7 23:40:22 2017 us=424321 Outgoing Control Channel Authentication: Using 224 bit message hash 'SHA224' for HMAC authentication
    Tue Mar  7 23:40:22 2017 us=424371 Incoming Control Channel Authentication: Using 224 bit message hash 'SHA224' for HMAC authentication
    Tue Mar  7 23:40:22 2017 us=424394 LZO compression initializing
    Tue Mar  7 23:40:22 2017 us=424528 Control Channel MTU parms [ L:1622 D:1176 EF:74 EB:0 ET:0 EL:3 ]
    Tue Mar  7 23:40:22 2017 us=424774 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
    Tue Mar  7 23:40:22 2017 us=424831 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1566,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher CAMELLIA-256-CBC,auth SHA224,keysize 256,tls-auth,key-method 2,tls-client'
    Tue Mar  7 23:40:22 2017 us=424849 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1566,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher CAMELLIA-256-CBC,auth SHA224,keysize 256,tls-auth,key-method 2,tls-server'
    Tue Mar  7 23:40:22 2017 us=424875 TCP/UDP: Preserving recently used remote address: [AF_INET]72.xx.xx.34:34448
    Tue Mar  7 23:40:22 2017 us=424904 Socket Buffers: R=[212992->212992] S=[212992->212992]
    Tue Mar  7 23:40:22 2017 us=424927 UDP link local (bound): [AF_INET][undef]:1194
    Tue Mar  7 23:40:22 2017 us=424945 UDP link remote: [AF_INET]72.xx.xx.34:34448
    WRTue Mar  7 23:40:22 2017 us=512612 TLS: Initial packet from [AF_INET]72.xx.xx.34:34448, sid=e13b09eb 8a42b86f
    Tue Mar  7 23:40:22 2017 us=512664 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]72.xx.xx.34:34448
    RTue Mar  7 23:40:24 2017 us=553308 TLS: Initial packet from [AF_INET]72.xx.xx.34:34448, sid=e13b09eb 8a42b86f
    Tue Mar  7 23:40:24 2017 us=553364 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]72.xx.xx.34:34448
    WRTue Mar  7 23:40:28 2017 us=708541 TLS: Initial packet from [AF_INET]72.xx.xx.34:34448, sid=e13b09eb 8a42b86f
    Tue Mar  7 23:40:28 2017 us=708592 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]72.xx.xx.34:34448
    WRTue Mar  7 23:40:33 2017 us=827386 TLS Error: Unroutable control packet received from [AF_INET]72.xx.xx.34:34448 (si=3 op=P_CONTROL_V1)
    WRTue Mar  7 23:40:36 2017 us=90125 TLS: Initial packet from [AF_INET]72.xx.xx.34:34448, sid=e13b09eb 8a42b86f
    Tue Mar  7 23:40:36 2017 us=90173 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]72.xx.xx.34:34448
    ^X^CTue Mar  7 23:40:38 2017 us=957848 event_wait : Interrupted system call (code=4)
    Tue Mar  7 23:40:38 2017 us=958051 TCP/UDP: Closing socket
    Tue Mar  7 23:40:38 2017 us=958108 SIGINT[hard,] received, process exiting
    ➜  openvpn



  • I was about to suggest that the client was missing the tls-auth directive but the server doesn't use one. This just might be a problem in the OpenSSL version Fedora uses, it doesn't support a particular HMAC algorithm or something else is different compared to the pfSense one.



  • Hmm in the very beginning, when I tried reusing the same 'server' as the Windows users use I did have to go in and manually enabled SHA1 because F25 right out of the box does not allow the dead crypto.  I wonder if by randomly choosing what I thought would be secure enough crypto options I chose something else that's unsupported?



  • Run 'openssl ciphers -v' to check what your client supports and modify the server and client settings to fit to the clients abilities.



  • Nice! Thanks Virago.  I dual boot so I'll do this after work and report back.



  • Sorry it took so long, here's what my openssl is supporting:

    [root@localhost bhart]# openssl ciphers -v
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH    Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH    Au=ECDSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH    Au=RSA  Enc=AES(256)  Mac=SHA384
    ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA384
    ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH    Au=RSA  Enc=AES(256)  Mac=SHA1
    ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(256)  Mac=SHA1
    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH    Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH    Au=ECDSA Enc=AESGCM(128) Mac=AEAD
    ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH    Au=RSA  Enc=AES(128)  Mac=SHA256
    ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA256
    ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH    Au=RSA  Enc=AES(128)  Mac=SHA1
    ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH    Au=ECDSA Enc=AES(128)  Mac=SHA1
    ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH    Au=RSA  Enc=3DES(168) Mac=SHA1
    ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH    Au=ECDSA Enc=3DES(168) Mac=SHA1
    AES256-GCM-SHA384      TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
    AES256-SHA256          TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
    AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
    CAMELLIA256-SHA        SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
    AES128-GCM-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
    AES128-SHA256          TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
    AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
    CAMELLIA128-SHA        SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
    DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
    DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH      Au=DSS  Enc=AESGCM(256) Mac=AEAD
    DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH      Au=RSA  Enc=AESGCM(256) Mac=AEAD
    DHE-RSA-AES256-SHA256  TLSv1.2 Kx=DH      Au=RSA  Enc=AES(256)  Mac=SHA256
    DHE-DSS-AES256-SHA256  TLSv1.2 Kx=DH      Au=DSS  Enc=AES(256)  Mac=SHA256
    DHE-RSA-AES256-SHA      SSLv3 Kx=DH      Au=RSA  Enc=AES(256)  Mac=SHA1
    DHE-DSS-AES256-SHA      SSLv3 Kx=DH      Au=DSS  Enc=AES(256)  Mac=SHA1
    DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH      Au=RSA  Enc=Camellia(256) Mac=SHA1
    DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH      Au=DSS  Enc=Camellia(256) Mac=SHA1
    DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH      Au=DSS  Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH      Au=RSA  Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-SHA256  TLSv1.2 Kx=DH      Au=RSA  Enc=AES(128)  Mac=SHA256
    DHE-DSS-AES128-SHA256  TLSv1.2 Kx=DH      Au=DSS  Enc=AES(128)  Mac=SHA256
    DHE-RSA-AES128-SHA      SSLv3 Kx=DH      Au=RSA  Enc=AES(128)  Mac=SHA1
    DHE-DSS-AES128-SHA      SSLv3 Kx=DH      Au=DSS  Enc=AES(128)  Mac=SHA1
    DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH      Au=RSA  Enc=Camellia(128) Mac=SHA1
    DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH      Au=DSS  Enc=Camellia(128) Mac=SHA1
    EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH      Au=RSA  Enc=3DES(168) Mac=SHA1
    EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH      Au=DSS  Enc=3DES(168) Mac=SHA1
    PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
    PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
    PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
    [root@localhost bhart]#

    So the lack of CAMELLA-256-CBC and RSA-SHA224  would be my problem.. yes?



  • Yes certainly, if the server supports CAMELLA-256-CBC and is set to use it the client better support it as well. Try to look deeper into the client log if you can see an error message indicating non supported ciphers and/or MACs.



  • Well after googling the past hour Im no closer to finding out the correct syntax to making sure OpenSSL can talk correctly to one of the few cipher OpenVPN supports.  And as far as more detailed logs, I cant find anything else in granular detail.