Tips & Tricks: Why Use a VPN Proxy ID?

Remember our dilemma from last week, where we had overlapping subnets over an IPSec VPN tunnel? We were looking for a way to get peer networks  communicating. Proxy IDs to the rescue. If you have a Palo Alto Networks firewall working with a peer supporting policy-based VPN, you'll need Proxy IDs.

 

Last week's Discussion of the Week (DotW) is Help with Proxy IDs, but let's talk more about VPN proxy IDs and why it is important to use them.

 

When we are talking about IPSec VPN tunnels, if you are setting up the Palo Alto Networks firewall to work with a peer that supports policy-based VPN, you must define proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access lists (source addresses, destination addresses and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as proxy IDs in the first or the second message of the process.

 

So, if you are configuring the Palo Alto Networks firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation, you must define the proxy ID so that the setting on both peers is identical. If the proxy ID is not configured, because the Palo Alto Networks firewall supports route-based VPN, the default values used as proxy ID are source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application: any; and when these values are exchanged with the peer, the result is a failure to set up the VPN connection.

 

Now, let's take a look at the Proxy ID window and options:

Inside the Proxy ID section, (located inside the WebGUI - Network > IPSec Tunnels > Select a Tunnel > Proxy IDs tab), you will see many options:

• Proxy ID — Click Add and enter a name to identify the proxy. Can be any Name. If only numbers are used, it will not be accepted.
• Local — Enter an IP address or subnet in the format ip_address/mask (for example, 10.1.2.1/24).
• Remote — If required by the peer, enter an IP address or subnet in the format ip_address/mask (for example, 10.1.1.1/24).
• Protocol - Specify the protocol and port numbers for the local and remote ports:
  • Number — Specify the protocol number (used for interoperability with third-party devices).
  • Any — Allow TCP and/or UDP traffic.
  • TCP — Specify the local and remote TCP port numbers.
  • UDP — Specify the local and remote UDP port numbers.

NOTE: Each proxy ID is counted as a VPN tunnel, and therefore counted towards the IPSec VPN tunnel capacity of the firewall. (Example: Site-toiSite IPSec VPN tunnel limit- PA-3020 - 1000, PA-2050 - 100, PA-200 - 25)

 

The advantage with the proxy IDs is the ability to get granular with protocol numbers or TCP/UDP port numbers if you have specific traffic you want to travel over the VPN tunnel only. Proxy IDs easily enable such granularity.

 

Because there are 2 versions of IKE, the behavior with proxy IDs is different:
- With IKEv1, Palo Alto Networks devices support only proxy-ID exact match. In the event where the Peer's Proxy ID's do not match, then there will be problems with the VPN working correctly.
- With IKEv2, there is support traffic selector narrowing when the proxy ID setting is different on the two VPN gateways, Only the implemented choice is described in the use cases below.

 

Use cases IKEv2

Please see below for a list of Use Cases with IPSEC and IKEv2 that can help explain many IPSEC VPN Setups, and how to properly use the Proxy ID's.

 

Example: There are two VPN gateways: A and B. IKE negotiation is started by VPN GW-a. i=initiator, r=responder

 

Suppose VPN GW-a defined traffic selector TSi-a/TSr-a; VPN GW-b has setting for traffic selector TSi-b/TSr-b. TSr-a is the same as TSr-b, so it can be ignored. TSi-a can be different from TSi-b.

 

A. TSi-a is the same as TSi-b, for example, both are 5.10.11.0/24.

Expected: Then there is no narrowing required, the behavior is the same as existing IKEv1 proxy ID case. Traffic would not be able to pass, in this example, NAT would be required to allow proper communication.

 

VPN GW-a: send: TSi: 5.10.11.0 - 5.10.11.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [ final result ]

 

This solution is detailed in the DotW article here:

Help with Proxy ID's

B. TSi-a is superset of TSi-b:

b1. VPN GW-a proposes TSi-a = 5.10.0.0/16; On VPN GW-b: TSi-b = 5.10.11.0/24.

 

i. Tunnel is brought up without traffic (for example, during initialization or by test command).

 

Expected: As the responder, VPN GW-b replies to VPN GW-a with 5.10.11.0/24. VPN GW-a should accept it and create CHILD SA.

 

VPN GW-a: send: TSi: 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [narrowed to the common subset]

 

ii. A host behind VPN GW-a (for example, host IP 5.10.11.2) tries to bring up the tunnel.

 

Expected: As the responder, VPN GW-b replies to VPN GW-a with 5.10.11.0/24. VPN GW-a should accept it and create CHILD SA. The traffic should pass.

 

VPN GW-a: sending: TSi: 5.10.11.2; 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [narrowed to the common subset]

 

If we are the initiator, we do not send out the first specific traffic selector (5.10.11.2) in IKE payload.

As a responder, we should be able to handle the peer who send the specific traffic selector. We will also narrow the traffic selector to the common subset.

 

iii. A host behind VPN GW-a (for example, host IP 5.10.6.2) tries to bring up the tunnel.

Expected: As the responder, VPN GW-b replies to VPN GW-a with 5.10.11.0/24. VPN GW-a should accept it and create CHILD SA.

 

VPN GW-a: send: TSi: 5.10.6.2; 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [narrowed to the common subset]

 

If we are the initiator, we do not send out the first specific traffic selector (5.10.6.2) in IKE payload.

 

As a responder, we will narrow the traffic selector to the common subset. If the received TS payload contains the specific traffic selector, although it is out of the local policy, we still do the narrowing but ignored the specific traffic selector per RFC 5996.

 

b2. VPN GW-a proposes TSi-a = 5.10.0.0/16; On VPN GW-b: there are more than one entries defined: TSi-b = 5.10.11.0/24 + 5.10.12.0/24.

 

i. Tunnel is brought up without traffic.

 

Multiple entries per traffic selector is supported by strongswan. So strongswan can be used to setup as VPN GW-b. If PANOS is GW-b, we need to configure multiple proxy-IDs.

 

VPN GW-a: send: TSi: 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [ PANOS: the common subset from the first matching entry ]

 

The above shows the result for PANOS as the responder (VPN GW-b). It replies to VPN GW-a with one of the entries: 5.10.11.0/24 or 5.10.12.0/24 (the first entry based on the order in "show vpn tunnel", alphabetical order of full tunnel name).

 

Some vendor (as VPN GW-b) may return a TS with both entries (5.10.11.0 - 5.10.11.255 + 5.10.12.0-5.10.12.255), but we only install the first entry.

 

ii. A host behind VPN GW-a (e.g. host IP 5.10.11.2) tries to bring up the tunnel.

Expected: As the responder, VPN GW-b replies to VPN GW-a with 5.10.11.0/24. The traffic should pass.

 

VPN GW-a: send: TSi: 5.10.11.2; 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [PAN-OS: the common subset from the first matching entry, preferring the policy that can cover 5.10.11.2 ]

 

If we are the initiator, we do not send out the first specific traffic selector (5.10.11.2) in IKE payload.

 

If we are the responder, we search all the configured proxy-ID until one entry can cover the specific traffic selector and can be narrowed or exact matched. If the specific traffic selector cannot be covered by the common subset, we still try to do the narrowing.

 

iii. After step ii, another host behind VPN GW-a (e.g. host IP 5.10.12.2) tries to reach the other end of the VPN.

Expected: As the traffic does not match the VPN tunnel previously created, another IPSec SA will be negotiated.

 

VPN GW-a: send: TSi: 5.10.12.2; 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.12.0 - 5.10.12.255 [ PANOS: the common subset from the first matching entry, preferring the policy that can cover 5.10.12.2 ]

 

At this time, VPN tunnels for both proxy-ID are up and passing traffic.

 

Some vendor may not start another IKE negotiation. They send packets using existing tunnel established in step ii although it doesn't match 5.10.12.2. We need to check the whole tunnel negotiation process to analyze this kind of behavior.

 

iv. A host behind VPN GW-a (for example, host IP 5.10.6.2) tries to reach the other end of the VPN (without step ii and iii).

 

Expected: Because there is no matching SA on VPN GW-a, it tries to negotiate with VPN GW-b. The response may be implementation dependent.

 

VPN GW-a: send: TSi: 5.10.6.2; 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.12.0 - 5.10.12.255 [ PANOS: the common subset from the first matching entry ]

 

v. After step iii, a host behind VPN GW-a (for example, host IP 5.10.6.2) tries to reach the other end of the VPN.

 

The initiator could use a previously established tunnel to forward the traffic to the peer. Choosing which tunnel can be vendor dependent.

 

b3. For VPN GW-b that doesn't support traffic selector narrowing

 

Some VPN device doesn't support traffic selector narrowing, e.g. Cisco IOS 15.0 replies NO_PROPOSAL_CHOSEN in this case.

 

Tunnel cannot be established and configuration must be changed.

 

C. TSi-a is subset of TSr-b:

VPN GW-a proposes TSi-a = 5.10.11.0/24; On VPN GW-b: TSr-b = 5.10.0.0/16.

 

i. Tunnel is brought up without traffic.

 

Expected: VPN GW-b replies 5.10.11.0/24. Tunnel is established using the common part of the traffic selectors (5.10.11.0/24).

VPN GW-a: send: TSi: 5.10.11.0 - 5.10.11.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [final result - the common subset]

 

ii. A host behind VPN GW-a (e.g. host IP 5.10.11.2) tries to bring up the tunnel.

 

Expected: A tunnel with traffic selector 5.10.11.0/24 is established. The traffic should be able to pass.

VPN GW-a: send: TSi: 5.10.11.2; 5.10.11.0 - 5.10.11.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [final result]

 

If we are the initiator, we does not send out the first specific traffic selector (5.10.11.2) in IKE payload.

 

As a responder, we should be able to handle the peer who send the specific traffic selector. We will pick the traffic selector from the initiator as it is smaller.

 

iii. A host behind VPN GW-a (for example, host IP 5.10.6.2) tries to bring up the tunnel

 

Expected:

VPN GW-a: send: TSi: 5.10.6.2; 5.10.11.0 - 5.10.11.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [final result]

 

When PAN-OS is the initiator, if there is no proxy ID or single proxy ID defined on the same tunnel interface, tunnel will be negotiated as above and traffic will be sent out through the tunnel.

 

In case of multiple proxy ID, we will continue to check other proxy ID (tunnel ID) to see if there is a match. If there is no match then the last proxy-ID is used to negotiate the tunnel and send out the traffic. This is the behavior defined in IPsec Multiple Phase 2 Associations.

 

If PAN-OS is the responder and another vendor running policy VPN is the initiator, it may not start tunnel negotiation as the packet is out of the range of its local policy. If it does start tunnel negotiation, we will use the initiator's traffic selector as it is narrower.

 

D. There is overlapping between TSi-a and TSr-b.

VPN GW-a proposes TSi-a = 5.10.0.0/16; On VPN GW-b: TSr-b = 5.10.11.0/24 + 5.9.0.0/24.

i. Tunnel is brought up without traffic.

 

Expected: VPN GW-b replies 5.10.11.0/24. Tunnel is established using the common part of the traffic selectors (5.10.11.0/24).

VPN GW-a: send: TSi: 5.10.0.0 - 5.10.255.255

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [final result - the overlapped subset]

 

ii. A host behind VPN GW-a (e.g. host IP 5.10.11.2) tries to bring up the tunnel.

 

Expected: A tunnel with traffic selector 5.10.11.0/24 is established. The traffic should be able to pass.

VPN GW-a: send: TSi: 5.10.11.2, 5.10.0.0 - 5.10.255.255 

VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [common subset]

 

If we are the initiator, we does not send out the first specific traffic selector (5.10.11.2) in IKE payload.

 

As a responder, we should be able to handle the peer who send the specific traffic selector. We will also narrow the traffic selector to the common subset.

 

iii. A host behind VPN GW-a (e.g. host IP 5.10.12.2 - within policy for VPN GW-a but outside of the policy for VPN GW-b) tries to bring up the tunnel.

 

Expected:

VPN GW-a: send: TSi: 5.10.12.2, 5.10.0.0 - 5.10.255.255
VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [ common subset ]

 

If PANOS is the initiator: The responder cannot find a range that is useful for 5.10.12.2 so it returns the common range (5.10.11.0/24). Tunnel can be established. we don't send out the specific traffic selector.

 

Based on our existing behavior defined in IPsec Multiple Phase 2 Associations, the packet will be sent out through this tunnel but could be dropped by the responder. The sending VPN tunnel may not notice it.

 

iv. A host behind VPN GW-a (e.g. host IP 5.9.0.2 - within policy for VPN GW-b but outside of the policy for VPN GW-a) tries to bring up the tunnel.

 

Expected:
VPN GW-a: send: TSi: 5.9.0.2, 5.10.0.0 - 5.10.255.255
VPN GW-b: reply: TSi: 5.10.11.0 - 5.10.11.255 [common subset]

 

If the initiator is PAN-OS, the proxy id 0.0.0.0/0 (if there is no proxy ID defined) or the last proxy ID (in case there are multiple proxy ID defined on the tunnel interface) is used in TSi.

 

The traffic could be dropped by the responder (policy-based VPN) as it violates the narrowed TS.
If the initiator is doing strict VPN policy checking (not PAN-OS), then IKE negotiation may not be triggered as it violates the VPN policy.

 

That concludes the Tips & Tricks. I hope you have learned something from this article.

 

As always, we welcome all feedback and suggestions below.

 

Stay secure!

Joe Delio