IPSec VPN with Dynamic Peers on Palo Alto Firewalls: An Overview

Establishing secure site-to-site or remote access VPN connections is a fundamental security requirement. Internet Protocol Security (IPSec) is a suite of protocols used to provide security services for IP networks. On Palo Alto Networks firewalls, IPSec VPNs can be configured between peers with static IP addresses or between a static peer and a dynamic peer.

This article focuses on the configuration and considerations when one side of the IPSec tunnel has a dynamic IP address, which is a common scenario for branch offices, remote users, or smaller sites that may not have a dedicated static IP.

Static vs. Dynamic Peers

The distinction lies in how the peers are identified and reachable:

• Static Peer: A VPN endpoint (typically the central firewall) with a fixed, known public IP address or FQDN that does not change. This peer is always reachable at the same network location.
• Dynamic Peer: A VPN endpoint (e.g., a remote firewall or client) whose public IP address is assigned dynamically by an ISP and can change over time. Its network location is not static.

For IPSec VPN tunnels on Palo Alto Networks firewalls, a connection can only be established between a static peer and a dynamic peer, or between two static peers. Establishing a tunnel between two peers with dynamic IP addresses is not supported . The peer with the static IP acts as the consistent listener, while the dynamic peer must initiate the connection.

Successfully setting up a VPN with a dynamic peer requires using identifiers other than a static IP address for the dynamic side, such as an FQDN, User FQDN (email address format), or a certificate.

IPSec Peer Configuration: Static Peer (Central Firewall)

The static peer (usually the central office or headquarters firewall) is configured to listen for incoming VPN connection requests from dynamic peers. Since it doesn't know the dynamic peer's IP address beforehand, its IKE Gateway must be set up accordingly.

IKE Gateway Configuration (Static Peer)

The IKE Gateway defines the parameters for the Internet Key Exchange (Phase 1) negotiation. Key settings for the static peer include:

• Version: Select IKEv1 or IKEv2. IKEv2 is generally recommended for better security and features.
• Interface: Select the external (public facing) interface that will receive VPN connection attempts.
• Local IP Address: (Optional but recommended for clarity) Can be set to the static public IP address of this firewall.
• Peer IP Address Type: Set this to Dynamic . This is crucial as it tells the firewall not to expect connections from a specific IP but to listen for incoming requests from any IP address, expecting the peer to identify itself.
• Local Identification: Typically set to the static public IP address of this firewall.
• Peer Identification: This must match the Local Identification configured on the dynamic peer . This is how the static peer verifies the identity of the incoming connection request. It could be an FQDN, User FQDN (email format), or the Subject/SAN of the dynamic peer's certificate, depending on the authentication method used.
• Authentication:
  • Pre-shared Key (PSK): Enter a secure, complex pre-shared key. This key must exactly match the one configured on the dynamic peer.
  • Certificate: Select the local certificate this firewall will present and optionally configure peer certificate validation (e.g., requiring a specific peer certificate or checking the CA). If using certificates, the Peer Identification setting becomes particularly important for matching the certificate details.
• Local Certificate (for Certificate Auth): Select the certificate this firewall will use to authenticate itself.
• Peer Certificate (for Certificate Auth validation): Can be left as 'Any' or configured to require a specific peer certificate or CA.
• Enable Passive Mode: Enable this option. This makes the static peer a responder only. It will not initiate the connection but will wait for connection requests from the dynamic peer.
• IKEv1/IKEv2 Exchange Mode: Configure phase 1 parameters (encryption, authentication, Diffie-Hellman group, lifetime). Ensure these match the dynamic peer. For IKEv1, choose Main Mode (preferred for PSK/Cert) or Aggressive Mode (faster but less secure, may be needed for some older dynamic clients). For IKEv2, the exchange is standardized.

PCNSE/PCNSA Note: Understand the implications of Passive Mode. Enabling it on the static peer is essential because it cannot know the dynamic peer's IP to initiate. The Peer IP Address Type 'Dynamic' and Passive Mode 'Enabled' are key indicators of a static peer configured for dynamic connections.

IPSec Peer Configuration: Dynamic Peer (Branch/Remote Firewall)

The dynamic peer is the side of the VPN connection whose public IP address changes. Because its IP is not fixed, it cannot be configured to receive unsolicited connection attempts from a static peer. Therefore, the dynamic peer must be configured to initiate the VPN connection.

IKE Gateway Configuration (Dynamic Peer)

The IKE Gateway settings on the dynamic peer define how it establishes the Phase 1 connection and identifies itself.

• Version: Select IKEv1 or IKEv2, matching the static peer's configuration.
• Interface: Select the external (public facing) interface from which the VPN connection will originate. This interface will likely receive the dynamic IP address from the ISP.
• Peer IP Address Type: Set this to the static public IP address or FQDN of the static peer. Although this peer has a dynamic IP, it knows the static peer's address and will initiate the connection to it.
• Local Identification: This is a crucial setting for dynamic peers . Since its IP is dynamic, it must identify itself to the static peer using a stable identifier that the static peer knows. This is typically configured as:
  • User FQDN (e.g., branch1@example.com ): A unique email-like format.
  • FQDN (e.g., branch1.example.com ): A fully qualified domain name. This FQDN usually needs to be resolvable to the dynamic peer's current IP (e.g., via Dynamic DNS).
  • Certificate (Subject or SAN): If using certificate-based authentication, the Local Identification is often derived from the certificate's Subject Name or Subject Alternative Name (SAN).
  This identifier MUST match the Peer Identification configured on the static peer.
• Peer Identification: Typically set to the static public IP address or FQDN of the static peer, matching the Local Identification on the static peer.
• Authentication:
  • Pre-shared Key (PSK): Enter the same secure, complex pre-shared key configured on the static peer.
  • Certificate: Select the local certificate this firewall will present. The certificate's Subject or SAN should contain the identifier used in the Local Identification setting.
• Local Certificate (for Certificate Auth): Select the certificate this firewall will use to authenticate itself. Its details should match the Local Identification.
• Peer Certificate (for Certificate Auth validation): Can be left as 'Any' or configured to require a specific peer certificate or CA.
• Enable Passive Mode: Do NOT enable this option. The dynamic peer must actively initiate the connection when needed (e.g., when interesting traffic is detected or on a keep-alive timer).
• IKEv1/IKEv2 Exchange Mode: Configure phase 1 parameters (encryption, authentication, Diffie-Hellman group, lifetime). Ensure these match the static peer. For IKEv1, Aggressive Mode is sometimes used by dynamic clients, but Main Mode is more secure if supported by the static peer's configuration (though the static peer must still be Passive). IKEv2 is preferred.

PCNSE/PCNSA Note: The Dynamic Peer MUST initiate the connection. Its IKE Gateway configuration reflects this by having the Static Peer's address (or FQDN) as the "Peer IP Address Type" (or "Peer Address") and Passive Mode disabled. The "Local Identification" using FQDN, User FQDN, or Certificate is key for identifying itself with a dynamic IP.

IPSec Tunnel, Security Policies, and Routing

Once the IKE Gateways are configured on both the static and dynamic peers for successful Phase 1 negotiation, the IPSec tunnel (Phase 2) and related network settings must be configured.

IPSec Tunnel Configuration (Both Peers)

The IPSec Tunnel configuration defines the parameters for encrypting and authenticating the actual data traffic (Phase 2).

• Tunnel Interface: Assign a tunnel interface (e.g., tunnel.1 ). This virtual interface represents the VPN tunnel and is used for routing traffic over the VPN. It must be placed in a security zone (e.g., 'VPN-Zone').
• IKE Gateway: Select the IKE Gateway configured in the previous steps that connects to the respective peer.
• IPSec Crypto Profile: Select or create an IPSec Crypto Profile. This defines the Phase 2 parameters:
  • IPSec Protocol: ESP (Encapsulating Security Payload) is standard for encryption and authentication.
  • Encryption: Choose the encryption algorithm (e.g., AES-128, AES-256, 3DES).
  • Authentication: Choose the authentication algorithm (e.g., SHA1, SHA256, MD5).
  • Diffie-Hellman (DH) Group: Select a DH group (e.g., Group 5, 14, 19, 20). This provides Perfect Forward Secrecy (PFS).
  • Lifetime: Define how long the Phase 2 Security Associations (SAs) are valid before renegotiation.
  The settings within the IPSec Crypto Profile MUST match exactly on both the static and dynamic peers.
• Tunnel Monitor (Optional but Recommended): Configure tunnel monitoring to check the reachability of a host on the remote side of the tunnel. This helps detect tunnel failures quickly and can influence dynamic routing.

Security Policies (Both Peers)

Security policies control which traffic is permitted to flow through the VPN tunnel. Policies are stateful and based on zones.

• Create security policies to allow the desired traffic between the zones connected by the VPN. For example, a policy allowing traffic from the internal LAN zone -> VPN-Zone, and another from VPN-Zone -> internal LAN zone, for the specific subnets being sent over the tunnel.
• The Source and Destination Zones will typically be your internal LAN zones and the dedicated VPN zone for the tunnel interface.
• Source and Destination Addresses should specify the subnets or hosts allowed to communicate over the VPN.

Routing (Both Peers)

Routing ensures that traffic destined for the remote network segment is directed into the IPSec tunnel interface.

• Create a Static Route in the virtual router associated with the tunnel interface's zone.
  • Destination: The remote subnet (the network behind the other VPN peer).
  • Interface: The IPSec tunnel interface (e.g., tunnel.1 ).
  • Next Hop: Set to 'None' or 'IP Address' (if using Tunnel Monitor with an IP).
• Alternatively, if using dynamic routing protocols (like BGP) over the VPN tunnel, ensure the tunnel interface is included in the routing configuration.

PCNSE/PCNSA Note: Remember that Phase 1 establishes the secure channel for key exchange (IKE Gateway settings), while Phase 2 encrypts the data traffic (IPSec Tunnel & Crypto Profile). Both phases require matching parameters on both sides. Don't forget Security Policies and Routing - the tunnel is useless without them allowing and directing traffic.

Dynamic Peer Authentication: User FQDN or FQDN

When the dynamic peer has a changing IP address, traditional IP address-based identification is not feasible for the static peer. Instead, a stable identifier is required.

Using FQDN or User FQDN

Palo Alto Networks firewalls can use a Fully Qualified Domain Name (FQDN) or a User FQDN (an email-like format) as the identifier for the dynamic peer in the IKE Phase 1 negotiation.

• FQDN: A standard domain name (e.g., branchsite.example.com ).
  • Requires a Dynamic DNS (DDNS) service running on the dynamic peer's side to update the DNS record whenever its public IP address changes.
  • The static peer's firewall resolves this FQDN via DNS lookup when a connection attempt comes in or when verifying the peer identity.
• User FQDN: An identifier in the format of an email address (e.g., dynamic_user@example.com ).
  • This format is often used by VPN clients (like GlobalProtect) but can also be used for site-to-site dynamic peer configurations on firewalls.
  • It does not necessarily require a public DNS record or DDNS, as it's primarily an identity string exchanged during IKE negotiation.

Configuration Steps

The key is to configure these identifiers correctly on both sides:

1. Dynamic Peer IKE Gateway: Set the Local Identification to the chosen FQDN or User FQDN (e.g., branch1.example.com or branch1@example.com ).
2. Static Peer IKE Gateway: Set the Peer Identification to exactly match the Local Identification configured on the dynamic peer (e.g., branch1.example.com or branch1@example.com ).

PCNSE/PCNSA Note: The pairing of Local Identification on the Dynamic Peer and Peer Identification on the Static Peer is critical when not using IP addresses for identification. Know the difference and use cases for FQDN and User FQDN.

Dynamic Peer Authentication: Certificates

Using digital certificates for IPSec authentication provides a more scalable and secure alternative to Pre-shared Keys, especially in environments with many dynamic peers. Certificates leverage Public Key Infrastructure (PKI) to verify identity.

How Certificate Authentication Works for Dynamic Peers

Instead of sharing a secret key, each peer uses a digital certificate issued by a trusted Certificate Authority (CA) to prove its identity during the IKE negotiation. The dynamic peer identifies itself to the static peer using information contained within its certificate, typically in the Subject or a Subject Alternative Name (SAN).

Configuration Steps

1. Generate or Import Certificates (Both Peers):
   • On each firewall (static and dynamic), generate a Certificate Signing Request (CSR) or import an existing certificate.
   • Ensure the certificate for the dynamic peer includes an FQDN or User FQDN in the Subject Alternative Name (SAN) extension . This FQDN/User FQDN will serve as the stable identifier regardless of the dynamic IP.
   • The certificates should be signed by a trusted CA. The CA certificate must be imported into the 'Trusted Root CA' list on both firewalls.
   • Navigate to Device > Certificate Management > Certificates to manage certificates.
   • Reference: Palo Alto Networks documentation on Importing a Certificate for IKEv2 Gateway Authentication .
2. Configure IKE Gateway (Both Peers):
   • Go to Network > Network Profiles > IKE Gateways.
   • Under the General tab, set the Authentication method to Certificate .
   • Select the appropriate Local Certificate (the certificate this firewall will present).
   • For the static peer, set Peer IP Address Type to Dynamic and the Peer Identification to match the FQDN or User FQDN found in the dynamic peer's certificate SAN/Subject.
   • For the dynamic peer, set Peer IP Address Type to the static peer's IP/FQDN, and the Local Identification to match the FQDN or User FQDN in its own certificate. The Peer Identification should match the static peer's Local Identification (usually its static IP or FQDN).
3. Configure Peer Certificate Validation (Optional but Recommended - Both Peers):
   • Under the Advanced Options of the IKE Gateway, you can specify criteria for validating the peer's certificate (e.g., requiring it to be signed by a specific CA profile, matching a specific Subject/SAN value, or checking for revocation using CRL or OCSP).
4. Hash and URL Method (IKEv2 Specific - Optional):
   • IKEv2 supports certificate exchange using Hash and URL, where peers exchange a hash of their certificate and a URL from which the full certificate can be downloaded. This can reduce IKE message size.
   • To use this, enable HTTP Certificate Exchange in the IKE Gateway and provide the URL where the certificate is hosted. Both peers must be configured and able to reach the specified URLs.
   • Reference: Palo Alto Networks guide on Exporting a Certificate for a Peer to Access Using Hash and URL .

PCNSE/PCNSA Note: Certificate-based authentication is often considered more secure than PSK. Understand how the certificate's Subject or SAN is used as the identifier in the IKE Gateway configuration (Local and Peer Identification fields) and the requirement for both peers to trust the issuing CA.

Important Considerations and Exam Notes

When working with IPSec VPNs, particularly with dynamic peers, keep the following points in mind. Many of these are common areas tested on the PCNSE/PCNSA exams.

IPSec VPN Static vs. Dynamic Peers Quiz

Test your knowledge on configuring and understanding IPSec VPNs with static and dynamic peers on Palo Alto Networks firewalls.

This quiz covers concepts relevant to the PCNSA and PCNSE exams.