Requirements on firewall for OpenVPN client
-
Hi,
We have been using the OpenVPN clients on different networks without problem, Nowadays We have a client in a enterprise where security is taken very seriously, so We have to request our requirements in order to enable the connection for our OpenVPN client, so We asked to open port UDP 1194, They apply this rule and They showed us the evidence, but When the client can not connect, the pfsense recorded this logs when the client try to connect
pid=0 DATA len=0
pid=0 DATA len=0
Sep 8 21:05:24 openvpn 45313 "IP public":52362 UDPv4 WRITE [54] to [AF_INET]"IP public":52362: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sep 8 21:05:24 openvpn 45313 "IP public":52362 TLS: Initial packet from [AF_INET]"IP public":52362, sid=8b983ae9 45359ec8
pid=0 DATA len=0
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Expected Remote Options hash (VER=V4): '9e7066d2'
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Local Options hash (VER=V4): '162b04de'
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Control Channel MTU parms [ L:1558 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Sep 8 21:05:24 openvpn 45313 "IP public":52362 LZO compression initialized
Sep 8 21:05:24 openvpn 45313 "IP public":52362 Re-using SSL/TLS contextIs there any special requirements to enable in his firewall in order to enable the correct connection?
What should I ask its security department to permit this connection?All the clients on different networks can connect normally, We have this problem only in this location.
Any idea?
-
There is no specific requirements, but sometimes UDP just doesn't works for some weird reason.
Switch to TCP, at least for the testing if works at all. -
Thank you for your comments, That is the strange thing about this situation, because all the other clients located in other networks use the connection by UDP and there is not problem, only when the user is in this particular network is that these logs are generated and the user can not connect. For this reason and knowing that the network handles many security measures is that I suppose we need to open something in your network to achieve communication, the question is what traffic should I request to allow this connection? The logs generated are:
TLS Error: cannot locate HMAC in incoming packet from [AF_INET]"IP publica Firewall del cliente":63800
"IP publica Firewall del cliente":50393 SIGUSR1[soft,tls-error] received, client-instance restarting
"IP publica Firewall del cliente":50393 TLS Error: TLS handshake failed
"IP publica Firewall del cliente":50393 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) -
My quick guess is that something (DPI system, or just ISP with weird hiccups) is messing with your connection.
"TLS key negotiation failed to occur within 60 seconds" usually should be read as "No packets was received at all, so no connection at all"I advise you to test with TCP connection, that will at least show you if client from this location can connect to your servers AT ALL.
-
My quick guess is that something (DPI system, or just ISP with weird hiccups) is messing with your connection.
"TLS key negotiation failed to occur within 60 seconds" usually should be read as "No packets was received at all, so no connection at all"I advise you to test with TCP connection, that will at least show you if client from this location can connect to your servers AT ALL.
It works!!!!!
Finally We got a solution, The problem was related with a rule in the Firewall, It was not related with NAT or port UDP 1194, The problem was a content filtering rule, When They made an exception for OpenVPN, the problem was gone.
Thank you for all your comments.