topic OpenVPN behind PaloAlto in General Topics

OpenVPN behind PaloAlto

Morneweg — Tue, 01 Dec 2015 07:56:00 GMT

Hi!

We can't get OpenVPN to work. Our Juniper-SA works well.

The setup is only working without Firewall:

Laptop (static IP 80.0.0.4) attachted to an switch and the OpenVPN server attached to the same switch (eth1, dmz)

Our Policies:

Monitor:

Konfig - OpenVPN server

DMZ:

iface eth1 inet static
address 80.0.0.5
netmask 255.255.255.248
gateway 80.0.0.1

Local:

iface eth0 inet static

address 172.16.0.2
netmask 255.255.255.0
gateway 172.16.0.254

I know about this:

https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html

But ist doesn't help 😞

Can anyone help me? Thanks a lot!

Error OpenVPN Client:

Mon Nov 23 11:59:33 2015 NOTE: --user option is not implemented on Windows
Mon Nov 23 11:59:33 2015 NOTE: --group option is not implemented on Windows
Mon Nov 23 11:59:33 2015 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015
Mon Nov 23 11:59:33 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Mon Nov 23 11:59:33 2015 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Nov 23 11:59:33 2015 Need hold release from management interface, waiting...
Mon Nov 23 11:59:34 2015 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'state on'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'log all on'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'hold off'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'hold release'
Mon Nov 23 11:59:34 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 11:59:34 2015 UDPv4 link local: [undef]
Mon Nov 23 11:59:34 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 11:59:34 2015 MANAGEMENT: >STATE:1448276374,WAIT,,,
Mon Nov 23 12:00:34 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Nov 23 12:00:34 2015 TLS Error: TLS handshake failed
Mon Nov 23 12:00:34 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Nov 23 12:00:34 2015 MANAGEMENT: >STATE:1448276434,RECONNECTING,tls-error,,
Mon Nov 23 12:00:34 2015 Restart pause, 2 second(s)
Mon Nov 23 12:00:36 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 12:00:36 2015 UDPv4 link local: [undef]
Mon Nov 23 12:00:36 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 12:00:36 2015 MANAGEMENT: >STATE:1448276436,WAIT,,,
Mon Nov 23 12:01:36 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Nov 23 12:01:36 2015 TLS Error: TLS handshake failed
Mon Nov 23 12:01:36 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Nov 23 12:01:36 2015 MANAGEMENT: >STATE:1448276496,RECONNECTING,tls-error,,
Mon Nov 23 12:01:36 2015 Restart pause, 2 second(s)
Mon Nov 23 12:01:38 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 12:01:38 2015 UDPv4 link local: [undef]
Mon Nov 23 12:01:38 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 12:01:38 2015 MANAGEMENT: >STATE:1448276498,WAIT,,,

Re: OpenVPN behind PaloAlto

Morneweg — Tue, 24 Nov 2015 15:32:58 GMT

Should I create routes on the interfaces!? If so, is this OK?

Chears!

Re: OpenVPN behind PaloAlto

glastra1 — Wed, 25 Nov 2015 00:12:26 GMT

It's easier if you have both interfaces in the same virtual router so you don't have to create routes. If the external (internet) interface and the internal (Open vpn server) interface are on different virtual routers you need to create inter-VR routing only a route in the "untrust" would be needed as the the return route (default route in trust VR) is already in place.

I recommend you to enable ping for the test and validate you can reach the server (it has 2 default routes which can cause problems).

Regards,

Gerardo,

Re: OpenVPN behind PaloAlto

Morneweg — Thu, 26 Nov 2015 09:21:56 GMT

Hi! I Have changed the following:

OpenVPN Server (client and server config:

tcp 443 (udp 1194 old config)

Now I can see this log entries:

routes only vr-untrust:

interfaces:

but it doesn't work 😞

Re: OpenVPN behind PaloAlto

Morneweg — Thu, 26 Nov 2015 10:31:48 GMT

I have created an Application Override:

https://live.paloaltonetworks.com/t5/Learning-Articles/Tips-amp-Tricks-How-to-Create-an-Application-Override/ta-p/65513

What is wrong? it doesn't work 😞

Re: OpenVPN behind PaloAlto

Morneweg — Fri, 27 Nov 2015 11:12:15 GMT

I have test a few confguration settings.

I have installed an ftp-server in the dmz with the ip-address: 80.0.0.5 and have set the rule to application "ftp" - THIS WORKS FINE!

But PaloAlto blocks OpenVPN Traffic 😞

Update Status (application defintions):

Policy Rules:

Monitor:

Capture (PaloAlto > Monitor > last action (deny in the screenshot above)

OpenVPN Server TCPDump:

Thanks four your support!

Re: OpenVPN behind PaloAlto

gtomte — Tue, 01 Dec 2015 09:09:52 GMT

I'm sending you different info to play with.

http://serverfault.com/questions/709860/fix-tls-error-tls-handshake-failed-on-openvpn-client

Check the detailed info for the session that says "insufficiant", to see if you have traffic in both directions.

Do a pcap on the fw, to see what happens. Is there a NAT problem?

You did an app override, for port 443, while all logs you are showing are port 1194. Perhaps you should one for port 1194 as well, plus adding the custom apps to the policy as well.

When doing a google search on "TLS handshake failed", there are many posts. Here's one of them:

- https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html

To better understand the messages the Monitor are giving you, read here:

- https://live.paloaltonetworks.com/t5/Management-Articles/Not-Applicable-Incomplete-Insufficient-Data-in-the-Application/ta-p/65711

Insufficient data in the application field

Insufficient data means not enough data to identify the application. So for example, if the three-way TCP handshake completed and there was one data packet after the handshake but that one data packet was not enough to match any of our signatures, then user will see insufficient data in the application field of the traffic log.

Meaning... The FW doesn't see enogh packets.

From this site: https://openvpn.net/index.php/open-source/documentation/howto.html

Troubleshooting

If the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:

You get the error message: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). This error indicates that the client was unable to establish a network connection with the server.

Solutions:
- Make sure the client is using the correct hostname/IP address and port number which will allow it to reach the OpenVPN server.
- If the OpenVPN server machine is a single-NIC box inside a protected LAN, make sure you are using a correct port forward rule on the server's gateway firewall. For example, suppose your OpenVPN box is at 192.168.4.4 inside the firewall, listening for client connections on UDP port 1194. The NAT gateway servicing the 192.168.4.x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192.168.4.4.
- Open up the server's firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).

Good luck.

Re: OpenVPN behind PaloAlto

gtomte — Tue, 01 Dec 2015 09:12:12 GMT

I see you use profiles. Anything in the threat logs? Have you tried a policy without profiles?