Policy Based VPN tunnels not fully connecting when Palo Alto is the remote peer

Products

• VMware NSX Networking

Issue/Introduction

A policy based VPN connection is configured to connect with a remote peer that is a Palo Alto device. The state of VPN is Success; however, not all tunnels are up.
The classic example is there are two remote networks configured and only one tunnel is up and the other is down.  Which one is up is dependent of which peer is the initiator.

Environment

NSX-T  Policy Base VPN connection to remote peer that is Palo Alto

Cause

The issue is that the Palo Alto device does not support policy based VPN connection.  There must be a special configuration implemented on the Palo Alto to address this issue.

Resolution

This is the Palo Alto documentation that address the issue with Policy Based VPN connections.

Proxy-ID for VPNs Between Palo Alto Networks and Firewalls with Policy-based VPNs

 188280

Created On 09/25/18 19:21 PM - Last Modified 06/27/24 01:17 AM

VPNs

PAN-OS

Next-Generation Firewall

Resolution

Difference between policy-based VPNs and route-based VPNs are:

Policy-based VPNs                                                                                                                                                                       

• The IPSEC tunnel is invoked during policy lookup for traffic matching the interesting traffic.                                  
• There are no tunnel interfaces. The remote end of the interesting traffic has a route pointed out through the default gateway.                                
• As there are no tunnel interfaces, we cannot have routing over VPNs.                                                                
• The polices/access-lists configured for the interesting traffic serve as the proxy-IDs for the tunnels.                        
• Firewalls that support policy-based VPNs: Juniper SRX, Juniper Netscreen, ASA, and Checkpoint.                                 

Route-based VPNs

• The IPSec tunnel is invoked during route lookup for the remote end of the proxy-IDs.
• The remote end of the interesting traffic has a route pointing out through the tunnel interface.
• Support routing over VPNs.
• Proxy-IDs are configured as part of the VPN setup.
• Firewalls that support route-based Firewalls: Palo Alto Firewalls, Juniper SRX, Juniper Netscreen, and Checkpoint.

Palo Alto Network firewalls do not support policy-based VPNs. The policy-based VPNs have specific security rules/policies or access-lists (source addresses, destination addresses and ports) configured for permitting the interesting traffic through IPSec tunnels. These rules are referenced during the quick mode/IPSec phase 2, and are exchanged in the 1st or the 2nd messages as the proxy-ids. If the Palo Alto Firewall is not configured with the proxy-id settings, the ikemgr daemon sets the proxy-id with the default values of source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application:any, and these are exchanged with the peer during the 1st or the 2nd message of the quick mode. A successful phase 2 negotiation requires not only that the security proposals match, but also the proxy-ids on either peer, be a mirror image of each other.

 So it is mandatory to configure the proxy-IDs whenever you establish a tunnel between the Palo Alto Network firewall and the firewalls configured for policy-based VPNs.

(https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClW8CAK)