Proxy IDs in IPSec VPNs: A Comprehensive Look

This article explores the concept of Proxy IDs (also known as Traffic Selectors) in the context of IPSec VPNs, particularly focusing on their usage and implications on Palo Alto Networks firewalls. We will cover their requirements, issues, routing considerations, and key points relevant for PCNSE/PCNSA candidates.

1. Understanding Proxy IDs

In Palo Alto Networks firewalls, a Proxy ID defines the local and remote subnets that are allowed to communicate over an IPSec VPN tunnel. They are crucial during the IKE Phase 2 negotiation to establish Security Associations (SAs) for specific traffic flows.

Essentially, Proxy IDs tell the VPN peers *what traffic* is intended to traverse the tunnel. They are pairs of (Source IP, Destination IP, Protocol, Source Port, Destination Port), although typically just the Source and Destination IP (subnets or hosts) are used.

2. Scenarios Requiring Proxy IDs

While Palo Alto Networks firewalls often simplify VPN configuration with route-based VPNs, Proxy IDs are mandatory or highly recommended in specific scenarios:

• Interoperability with Policy-Based VPN Peers: When connecting to devices that use policy-based VPNs (e.g., older Cisco ASA configurations, some other vendors), Proxy IDs must be configured to match the peer's defined policies exactly. The remote device relies on the received Proxy IDs to build its security associations (SAs).
• Multiple Tunnels Between the Same Peers: If multiple IPSec tunnels exist between the same pair of devices (e.g., one tunnel for voice traffic, one for data), distinct Proxy IDs are used to differentiate the traffic and ensure it goes into the correct SA/tunnel.
• Granular Traffic Control: Defining specific Proxy IDs allows for precise control over which subnets or hosts can communicate over the VPN, even if route-based VPNs are used. This acts as an implicit traffic filter at the tunnel negotiation phase.

3. When Proxy IDs Are Not Required

• Palo Alto to Palo Alto Route-Based VPNs: When both peers are Palo Alto firewalls using route-based VPNs, Proxy IDs are generally optional. The firewalls default to using 0.0.0.0/0 for both local and remote subnets in the IKEv2 negotiation. This indicates "all traffic" and the actual traffic allowed is controlled by security policies and routing, not the Proxy ID itself. This simplifies configuration significantly.

4. Configuring Proxy IDs (Palo Alto Networks)

To configure Proxy IDs on a Palo Alto firewall:

1. Navigate to Network > IPSec Tunnels and select the desired tunnel.
2. Click on the Proxy IDs tab.
3. Click Add and enter:
   • Name: A unique identifier for the Proxy ID (e.g., "Internal-to-Branch").
   • Local: The local subnet or host (e.g., 192.168.1.0/24 ). This should match the Source IP in your security policy rules for traffic going over this tunnel.
   • Remote: The remote subnet or host (e.g., 10.0.0.0/24 ). This should match the Destination IP in your security policy rules.
   • Protocol: Specify a protocol (e.g., tcp , udp ) or leave as any (typically leave as any unless required by peer).
   • Local Port: Specify if needed (typically leave as any ).
   • Remote Port: Specify if needed (typically leave as any ).
4. Click OK to save the configuration.
5. Repeat for all necessary subnet pairs.
6. Commit the changes.

Ensure that the Proxy IDs match exactly on both VPN peers (local on one side is remote on the other, and vice versa) to establish a successful IKE Phase 2 Security Association for that specific traffic flow.

5. Considerations

• IKE Version Differences: With IKEv1, Proxy IDs must match exactly on both peers for the Phase 2 SA to negotiate. IKEv2 supports Traffic Selector narrowing . This means if one side proposes broader subnets (e.g., 0.0.0.0/0), the other side can propose narrower subnets (e.g., 192.168.1.0/24 to 10.0.0.0/24), and the tunnel will establish using the *narrower* proposed subnets. This provides some flexibility but exact matches are still the safest approach for interoperability.
• Firewall Capacity: Each configured Proxy ID is considered a separate VPN tunnel for licensing and capacity purposes on some firewall models. Be mindful of the limit if you have many granular Proxy IDs defined.

Proxy ID Requirements for IKEv1 and IKEv2

The behavior and requirements of Proxy IDs differ between IKEv1 and IKEv2, primarily due to the IKEv2 standard introducing more flexibility in Traffic Selector negotiation.

IKEv1 and Proxy IDs (Traffic Selectors)

In IKEv1 Phase 2:

• The initiator proposes a set of traffic selectors (Proxy IDs).
• The responder must accept one of the proposed sets *exactly* as it was proposed.
• If the responder's configured local/remote networks for the tunnel do not *exactly* match any of the initiator's proposed Proxy IDs (when considering the initiator's local as the responder's remote, and vice versa), the Phase 2 negotiation will fail with a Proxy ID mismatch error.
• This strict matching requirement in IKEv1 is a common source of VPN configuration issues, especially when dealing with devices from different vendors or differing configurations.
• Palo Alto Networks firewalls, even when configured for route-based VPNs and defaulting to 0.0.0.0/0, will still send 0.0.0.0/0 as the Traffic Selector if the peer is IKEv1.

IKEv1 Phase 2 Negotiation with Strict Proxy ID Matching.

IKEv2 and Proxy IDs (Traffic Selectors)

IKEv2 introduces more sophisticated Traffic Selector negotiation:

• The initiator proposes a set of traffic selectors (TSi, TSr).
• The responder also has its own set of traffic selectors (TSi', TSr').
• The peers negotiate to find a set of Traffic Selectors that are the *intersection* or a *subset* (narrowing) of both proposed sets.
• If Peer A proposes L1/R1 and Peer B proposes L2/R2, the resulting SA will cover traffic from (L1 ∩ R2) to (R1 ∩ L2). If the intersection is empty or invalid, negotiation fails.
• This narrowing capability means exact matches aren't strictly required if one side proposes broader ranges. For example, if Palo Alto A (route-based, 0.0.0.0/0) connects to Cisco B (policy-based, 192.168.1.0/24 to 10.0.0.0/24), the IKEv2 negotiation can successfully establish an SA for the 192.168.1.0/24 to 10.0.0.0/24 range.
• However, it's still best practice to configure matching Proxy IDs on both sides to be explicit and avoid potential issues, especially when interoperating with different vendors, even if they support IKEv2. Explicit configuration makes troubleshooting easier.

IKEv2 Phase 2 Negotiation with Traffic Selector Narrowing.

Issues Relating to Proxy ID Mismatch

A Proxy ID mismatch is one of the most common reasons for IPSec VPN tunnels failing to establish Phase 2 (SA negotiation) or for traffic not flowing correctly even if Phase 1 is up. This occurs when the local and remote subnets/hosts configured on one VPN peer for a specific tunnel do not match the corresponding remote and local subnets/hosts configured on the other peer for the same tunnel.

How a Mismatch Prevents SA Establishment (IKEv1 & IKEv2)

• IKEv1: As discussed, IKEv1 requires an *exact* match. If Peer A proposes 192.168.1.0/24 -> 10.0.0.0/24, Peer B MUST be configured for 10.0.0.0/24 -> 192.168.1.0/24 for that specific tunnel's Phase 2 to come up. Any deviation (e.g., different subnet mask, a single host instead of a subnet, a different protocol specified) will result in a Phase 2 failure, often indicated by logs showing "NO_PROPOSAL_CHOSEN" or "Traffic selector mismatch".
• IKEv2: While IKEv2 supports narrowing, a mismatch can still occur if the proposed traffic selectors on both sides have no overlapping intersection. For example, if Peer A proposes 192.168.1.0/24 -> 10.0.0.0/24 and Peer B proposes 192.168.2.0/24 -> 10.0.0.0/24, there is no common source subnet, and the negotiation for that specific traffic flow will fail. Even with narrowing, configuring exact matches is crucial for predictability and troubleshooting.

Symptoms of Proxy ID Mismatch

• Phase 2 Failure: The most immediate symptom is that the IPSec Security Association (SA) for the specific traffic flow will not come up. You might see Phase 1 up, but Phase 2 remains down or flaps.
• Traffic Blackholing: If Phase 1 is up but Phase 2 for the relevant Proxy ID is down, traffic destined for the remote network will likely be dropped or routed incorrectly (e.g., out the default route) instead of traversing the tunnel. Packets matching the mismatched Proxy ID definition will not find an active SA.
• One-Way Traffic: A less common but possible issue is when Proxy IDs are only partially mismatched or asymmetric. This could potentially lead to one side successfully encrypting and sending traffic, but the other side not having the corresponding SA to decrypt it, resulting in one-way communication.
• VPN Monitoring Alarms: Monitoring tools or the firewall's status pages will show the IPSec tunnel state as "down" or report Phase 2 errors.

Flowchart illustrating the impact of Proxy ID mismatch on traffic flow and tunnel establishment.

Common Causes of Mismatch

• Typos: Incorrect IP addresses or subnet masks (e.g., /24 instead of /25 ).
• Reversal: Local and Remote are swapped on one side compared to the other.
• Missing Proxy IDs: Required Proxy IDs are simply not configured on one or both sides.
• Incorrect Protocol/Ports: If a specific protocol or port is defined on one side but not the other (or is different), the match will fail for that flow. Best practice is usually to use 'any' unless specifically required.
• NAT/PAT Issues: Traffic selectors should typically reflect the pre-NAT source IP and post-NAT destination IP from the perspective of the encrypting firewall. If NAT is involved, ensure the Proxy IDs reflect the correct IP addresses used in the tunnel communication. For outbound traffic through a VPN, the source Proxy ID should be the host's actual IP (pre-NAT) and the destination the remote network's actual IP. For inbound traffic, the source Proxy ID should be the remote network's actual IP and the destination the local host's actual IP.
• Multiple Proxy IDs: If multiple Proxy IDs are used, ensure all required pairs are configured correctly and reciprocally on both sides.

Routing with Proxy IDs and No Tunnel Interface IP

When using policy-based VPNs, or Palo Alto Networks route-based VPNs configured with specific Proxy IDs (especially when interoperating with policy-based peers), it is common for the tunnel interface itself not to have an IP address configured. This is different from typical route-based VPNs where a tunnel interface gets an IP address (often from a /30 or /31 ) for next-hop routing.

How Routing Works in This Scenario

In this setup, routing is not based on a traditional IP next-hop towards the tunnel interface IP. Instead, routing relies on:

1. Static or Dynamic Routes Pointing to the Tunnel Interface (Logical Interface): You configure a static route for the remote network (defined in your Proxy IDs) with the next hop being the IPSec tunnel logical interface itself (e.g., tunnel.1 ). The firewall knows that traffic matching this route should be considered for encryption over the specified tunnel.
2. Proxy ID Matching (Policy-Based peers or specified on Palo Alto): The firewall checks if the traffic flow (source IP, destination IP, protocol, ports) matches any of the configured Proxy IDs for the tunnel that the route points to.
3. Security Association (SA) Existence: If a matching Proxy ID is found, the firewall then checks if an active IKE Phase 2 SA exists for that specific Proxy ID (or a broader range that encompasses it in IKEv2).
4. Security Policy: Finally, the firewall evaluates security policies. There must be a security policy rule allowing the traffic flow from the source zone to the destination zone, utilizing the tunnel interface as the egress interface zone (typically a dedicated 'vpn' zone or the zone assigned to the tunnel interface).

Flowchart showing the logic for routing and processing traffic over an IPSec tunnel without a tunnel interface IP.

Key Differences from Next-Hop Routing

• No IP Address on Tunnel Interface: The tunnel interface acts purely as a logical anchor point for the route and IPSec configuration, not as a standard network interface with an IP participate in routing protocols directly (unless a virtual router interface is used for dynamic routing, but the tunnel itself still might not have an IP).
• Policy/Proxy ID Driven: The decision to encrypt is driven by the combination of the route pointing to the tunnel AND the traffic matching a negotiated Proxy ID, rather than simply forwarding to a next-hop IP on the tunnel.
• Simplified Setup (in some cases): Eliminates the need to manage a dedicated /30 or /31 subnet for tunnel endpoints.

For PCNSE/PCNSA: Understand that a route pointing to a tunnel interface without an IP requires the firewall to perform a Proxy ID lookup (if Proxy IDs are defined/required) before it can use an SA. If no matching SA is up for the traffic flow because of a Proxy ID mismatch, the traffic will not traverse the tunnel, even if the static route exists and Phase 1 is up.

Gotcha: If you configure a route to tunnel.X but configure NO Proxy IDs (and the peer expects specific ones, especially IKEv1 Policy-Based), Phase 2 will fail for those expected flows, and your traffic won't go, even though the route exists. Conversely, if you define Proxy IDs but no route points to the tunnel for those remote networks, traffic won't even attempt the tunnel. Both routing and Proxy IDs must align.

Palo Alto Networks VPN Types: Route-Based vs. Policy-Based

Palo Alto Networks firewalls primarily utilize route-based VPNs but also support policy-based VPNs for interoperability. Understanding the difference is crucial.

Policy-Based VPNs

Policy-based VPNs rely on access control lists (ACLs) or policies (often called "crypto maps" on Cisco) to define which traffic should be encrypted over the tunnel. Each defined traffic flow (source/destination IP, protocol/port - the Proxy IDs) results in a separate pair of Security Associations (SAs) being negotiated in IKE Phase 2.

• Traffic Selection: Done by matching traffic against configured policies/ACLs (Proxy IDs).
• Routing: Standard routing tables direct traffic towards the peer's external IP address. The firewall intercepts traffic matching the crypto policy *before* it's routed out the physical interface.
• Interface: Often associated with a physical interface, not a dedicated tunnel interface with an IP address.
• Complexity: Can become complex to manage with many specific traffic flows, as each flow requires a separate policy entry and potentially a unique SA pair.
• Interoperability: Necessary for connecting to older VPN devices or those that only support policy-based tunnels.
• On Palo Alto: Configured under Network > IPSec Tunnels, where you explicitly add Proxy IDs under the Proxy IDs tab. The tunnel object is associated with a Virtual Router and a Zone, and static routes point to the tunnel interface, but the *matching* against Proxy IDs is the critical step before encryption.

Route-Based VPNs

Route-based VPNs use virtual tunnel interfaces (VTIs) and standard IP routing to direct traffic into the tunnel. Traffic selection is implicitly handled by the routing table.

• Traffic Selection: Done by the routing table. If a packet's destination is reachable via a route pointing to a tunnel interface, the firewall knows that traffic should traverse that tunnel.
• Routing: Standard IP routing protocols (static, OSPF, BGP) are used over the virtual tunnel interfaces. The tunnel interface itself is typically assigned an IP address (often a point-to-point /30 or /31).
• Interface: Uses a dedicated logical tunnel interface (e.g., tunnel.1 , tunnel.2 ) which can participate in routing protocols or have static routes configured.
• Complexity: Generally simpler to manage, especially for complex topologies or when dynamic routing is used, as traffic selection is separated from the encryption policy.
• Interoperability: The modern standard for many VPN implementations. Palo Alto Networks firewalls default to this type. When interoperating with policy-based peers, you *must* add explicit Proxy IDs to the Palo Alto tunnel object, effectively making it *behave* like a policy-based peer during negotiation, while still using route-based concepts locally.
• On Palo Alto: Configured under Network > Interfaces > Tunnel, assigning an IP, Virtual Router, and Zone. The IPSec tunnel object then references this tunnel interface. By default (if no Proxy IDs are added under the IPSec tunnel's Proxy IDs tab), Palo Alto uses 0.0.0.0/0 for IKEv2 negotiations (or sends 0.0.0.0/0 TS in IKEv1), relying solely on routing and security policy for traffic control.

Caveats & PCNSE Relevance

• PCNSE/PCNSA Exam Note: Understand that while Palo Alto uses route-based concepts internally (tunnel interfaces, virtual routers), configuring Proxy IDs on the IPSec tunnel object forces it to interact with peers like a policy-based device during SA negotiation. This is the key for interoperability.
• Gotcha 1: Connecting a Palo Alto (route-based, no explicit Proxy IDs) to a policy-based peer (e.g., Cisco ASA with crypto maps) will fail Phase 2 unless you configure matching Proxy IDs on the Palo Alto. The Cisco will propose specific Proxy IDs based on its crypto map, and the Palo Alto needs corresponding ones defined to accept.
• Gotcha 2: Even with route-based VPNs, if you add explicit Proxy IDs on the Palo Alto, ONLY traffic matching those specific Proxy IDs (and allowed by security policy/routing) will traverse the tunnel. Traffic outside those Proxy IDs will NOT.
• Gotcha 3 (NAT): If NAT is involved, Proxy IDs must reflect the IPs after the NAT action for the tunnel. For traffic *originating* from behind the firewall and going *through* the tunnel, the local Proxy ID is the *original* source IP (pre-NAT), and the remote is the destination IP. The security rule should match the pre-NAT source and destination zones, but use the tunnel zone as the egress zone.

Comparison of traffic flow logic in Policy-Based vs. Route-Based VPNs.

PCNSE/PCNSA: Proxy ID Key Points & Gotchas

For candidates preparing for Palo Alto Networks certifications, a solid understanding of Proxy IDs, especially in interoperability scenarios, is essential.

Key Concepts to Master:

• Definition: What a Proxy ID (Traffic Selector) is - the local and remote subnets/hosts/protocols intended for encryption over a specific tunnel.
• Purpose: To define the scope of traffic for an IKE Phase 2 Security Association (SA).
• When Required: Primarily when connecting to policy-based VPN peers or needing granular SAs for multiple flows between the same peers.
• When Optional/Not Required: PA-to-PA route-based VPNs (defaulting to 0.0.0.0/0).
• Configuration Location: Under the IPSec Tunnel object in the GUI (Network > IPSec Tunnels > [Tunnel Name] > Proxy IDs tab).
• Matching: The critical need for reciprocal matching between peers, especially in IKEv1.
• IKEv2 Narrowing: The ability of IKEv2 to negotiate a subset of proposed Traffic Selectors.
• Relation to Security Policy and Routing: Proxy IDs define what *can* be encrypted; Security Policy defines what is *allowed*; Routing defines the path the firewall *considers* for encryption. All three must align.

Common Exam Gotchas & Pitfalls:

• Policy-Based Peer Interop: Failing to configure explicit Proxy IDs on the Palo Alto when the peer is policy-based. The exam often tests this specific scenario.
• Exact Match Requirement (IKEv1): Overlooking the strict matching needed for IKEv1 Proxy IDs (subnet masks, protocols, etc.).
• NAT and Proxy IDs: Confusing pre-NAT and post-NAT IPs in Proxy ID definitions. Remember Proxy IDs are about the *traffic* itself, often meaning pre-NAT source and post-NAT destination from the firewall's perspective.
• Mismatch Troubleshooting: Not knowing the correct CLI commands to identify Proxy ID mismatches (e.g., debug ike-gw on , less mp-monitor.log , show vpn flow ).
• Route vs. Proxy ID: Assuming that just having a route to the tunnel interface is enough for traffic to be encrypted, neglecting the need for a corresponding Proxy ID/SA if required by the peer or configuration.
• Proxy IDs and Capacity: Forgetting that each Proxy ID counts towards the tunnel capacity on some models.
• Default 0.0.0.0/0: Understanding that this is the default *sent* by Palo Alto in route-based IKEv2 (and IKEv1) when no explicit Proxy IDs are configured, but the *peer* might not accept it if it's policy-based with specific crypto maps.

Always check the remote peer's configuration when troubleshooting Proxy ID issues. The mismatch is almost always because one side's definition isn't the reciprocal of the other side's.

CLI Commands for Debugging Proxy ID Issues

Effective use of the Palo Alto Networks CLI is essential for troubleshooting VPN tunnels, especially when Proxy ID mismatches are suspected. These commands are run in the operational mode.

• show vpn ipsec-sa

  Shows the status of the IPSec Security Associations (Phase 2). Look for the tunnel name and check if SAs are established. If SAs are up, it will list the negotiated Traffic Selectors (Proxy IDs) for that SA. Compare these against your configuration and the remote peer's configuration. If no SAs are listed or the Tunnel column shows 'down', Phase 2 failed.

  > show vpn ipsec-sa
  gateway tunnel state local-ip remote-ip outer-tfr(Byte) inner-tfr(Byte)
  ---------------- ---------------- ------ --------------- --------------- --------------- ---------------
  BranchGW BranchTunnel active 1.1.1.1 2.2.2.2 1024000 980000
  
  > show vpn ipsec-sa tunnel BranchTunnel detail
  IPSec SA (tunnel BranchTunnel)
  --------------------------------------------------------------------------------
  State: active
  -- snip --
  Life Size Remaining: 100000 KB
  Life Time Remaining: 28800 secs
  -- snip --
  Traffic Selectors:
  Local: 192.168.1.0/24
  Remote: 10.0.0.0/24
  -- snip --

  Example output showing active SA and negotiated Traffic Selectors.

• show vpn ike-sa

  Shows the status of the IKE Security Associations (Phase 1). Check that Phase 1 is up (state 'active' or 'up'). If Phase 1 is down, the issue is likely before Proxy ID negotiation, but an unstable Phase 1 can cause Phase 2 flapping.

  > show vpn ike-sa
  gateway state local-ip remote-ip local-id remote-id
  ---------------- -------- --------------- --------------- ---------------- ----------------
  BranchGW active 1.1.1.1 2.2.2.2 id@local.com id@remote.com
• less mp-monitor.log or less ikemgr.log

  These are the primary logs for IKE and IPSec events. Search for your remote peer's IP address or the tunnel name. Look for messages related to "Traffic selector mismatch", "NO_PROPOSAL_CHOSEN", "Phase 2 negotiation failed". This log will often provide the exact Proxy ID values being proposed and why they are rejected.

  > less mp-monitor.log | match "remote_peer_ip"
  > less mp-monitor.log | match "Traffic selector mismatch"
  > less ikemgr.log

  Using 'less' and 'match' to filter log output.

• debug ike-gateway <gateway-name> on debug

  Enables detailed IKE debugging for a specific gateway. This is very verbose and should be used cautiously in production. It writes extensive negotiation details to the logs ( mp-monitor.log / ikemgr.log ). Remember to turn it off with debug ike-gateway <gateway-name> off .

  > debug ike-gateway BranchGW on debug
  > less mp-monitor.log # Now contains detailed debug output
  ... look for lines showing Traffic Selector details ...
  > debug ike-gateway BranchGW off # IMPORTANT: Turn off debug
• test vpn ike-sa gateway <gateway-name>

  Initiates an IKE Phase 1 negotiation attempt for the specified gateway. Useful to see if Phase 1 comes up clean before troubleshooting Phase 2/Proxy IDs.

  > test vpn ike-sa gateway BranchGW
• test vpn ipsec-sa tunnel <tunnel-name>

  Initiates an IKE Phase 2 negotiation attempt for the specified tunnel. Useful after confirming Phase 1 is stable to specifically test Phase 2 and see negotiation results/failures in the logs.

  > test vpn ipsec-sa tunnel BranchTunnel

Exam Tip: Be familiar with show vpn ipsec-sa and knowing where to find the negotiated Traffic Selectors. Also, know that mp-monitor.log or ikemgr.log are where detailed negotiation errors like mismatch appear.

Interactive Quiz: Proxy IDs and IPSec VPNs

Test your knowledge on Palo Alto Networks Proxy IDs and IPSec VPNs. Select the best answer for each question and click "Submit Quiz" at the end.