OpenVPN behind PaloAlto

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

OpenVPN behind PaloAlto

L1 Bithead

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:

palo-config-policy3.png

 

Monitor:

palo-config-monitor.png

 

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

 

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

 

7 REPLIES 7

L1 Bithead

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

 

palo-untrust.png

 

palo-trust.png

 

Chears!

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,

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:

palo-monitor-incomplete.png

 

routes only vr-untrust:

palo-untrust-only.png

 

interfaces:

palo-interfaces.png

 

but it doesn't work 😞

I have created an Application Override:

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

 

What is wrong? it doesn't work 😞

 

1over01.png

2over01.png

over01.png

over02.png

over03.png

over04.png

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):

04update-status.png

 

Policy Rules:

01policy.png

 

Monitor:

02monitor.png

 

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

03capture-palo.png

 

OpenVPN Server TCPDump:

 

05tcpdump.png

 

Thanks four your support!

L3 Networker

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

 

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

https://live.paloaltonetworks.com/t5/Management-Articles/Not-Applicable-Incomplete-Insufficient-Data...

 

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.

L3 Networker

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

  • 5377 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!