IPSec IKEv2 VPN Configuration for Cisco ASA and Palo Alto Firewall

What this guide covers

The accompanying video demonstrates IKEv2 with pre-shared-key authentication. This guide adds a planning and troubleshooting workflow grounded in the vendor documentation linked below. Menu labels and supported algorithms depend on the software release. Choose mutually supported cryptography that meets your organization’s requirements, use a strong unique pre-shared key, and keep that secret out of configuration examples and screenshots.

The configuration approach here uses an ASA crypto map with a Palo Alto tunnel interface. It does not assume that every ASA deployment uses crypto maps; ASA also supports other VPN designs.

Plan the peers and protected networks

Separate the public peer addresses from the private networks carried inside the VPN. The following addresses are illustrative lab values, not settings from the recording or addresses to deploy unchanged.

Record the IKE version, authentication method, peer identities, IKE encryption/integrity/PRF and Diffie-Hellman settings, plus the IPsec encryption/integrity and PFS requirements. IKE authenticates the peers and establishes the IKE security association; the IPsec CHILD security associations protect the selected data traffic. Compatible proposals are necessary at both layers.

Build both sides of the connection

Configure the ASA peer

Define an IKEv2 policy and an IKEv2 IPsec proposal. Configure the peer’s LAN-to-LAN tunnel group with the intended authentication settings, including the local and remote pre-shared-key entries. The crypto map ties together the remote peer, IPsec proposal and crypto access list that identifies protected traffic. Apply that map to the intended outside interface and enable IKEv2 there. Review existing map entries and IKE policies before choosing names and sequence numbers. See the Cisco ASA LAN-to-LAN configuration guide.

Configure the Palo Alto peer

Create a tunnel interface assigned to the correct security zone and virtual router. Configure an IKE gateway for the ASA’s public address and authentication, attach the appropriate IKE and IPsec crypto profiles, and associate the gateway with the IPsec tunnel. Add a route for the remote protected network through the tunnel interface. Define Security policy rules for the required traffic between the internal and VPN zones; a negotiated tunnel alone does not supply application access. Palo Alto’s site-to-site VPN workflow explains these components.

Mirror the traffic selectors

The ASA’s local subnet is the Palo Alto peer’s remote subnet, and vice versa. For the example above, the ASA protects traffic from 10.10.10.0/24 to 10.20.20.0/24; the Palo Alto selector reverses those networks. PAN-OS uses the Proxy IDs tab to configure IKEv2 traffic selectors. Match the negotiated address ranges and any protocol/port restrictions to the ASA crypto ACL. See Palo Alto’s traffic-selector guidance.

Review NAT and policy order

If original private addresses must cross the VPN, prevent general Internet PAT from translating that traffic. On the ASA, use an appropriate identity NAT rule for the local-to-remote network pair. Check rule order: an earlier matching translation can defeat the intended exemption. Review the Palo Alto NAT policy for the same flow. Cisco documents site-to-site NAT exemption and NAT processing order.

Verify negotiation and traffic

Generate traffic between hosts in the protected subnets. On the ASA, inspect the IKEv2 and IPsec security associations with these read-only commands:

show crypto ikev2 sa
show crypto ipsec sa

Confirm the intended peer and selectors, then compare encapsulation and decapsulation counters while testing both directions. Cisco’s IKEv2 verification example explains these outputs.

On the Palo Alto firewall, inspect the matching associations:

show vpn ike-sa
show vpn ipsec-sa

Check Traffic and System logs alongside these commands. An established security association proves negotiation; a successful application test confirms the useful result.

Troubleshoot in layers

• No IKE association: check peer reachability, the configured peer identity, authentication and compatible IKE proposals.
• IKE established, no usable IPsec association: compare IPsec proposals and both peers’ traffic selectors.
• Tunnel established, no traffic: follow the route, NAT decision and security policy in each direction. Confirm the test host belongs to the negotiated subnet.
• Only one direction works: compare packet counters and the return route. Check the destination host’s own firewall and whether replies return through the same VPN.

Change one identified mismatch at a time and repeat the same end-to-end test. Palo Alto’s VPN troubleshooting workflow provides a methodical path from basic connectivity to policy and packet analysis.