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