top of page

Palo Alto IKE Phase-1 Up, Phase-2 Down: Proxy-ID CLI That Most Teams Skip

  • Aug 15
  • 2 min read
Palo Alto network security troubleshooting lab
Palo Alto · Techclick CLI troubleshooting lab
Site-to-site VPN tunnel is green on Phase-1. Interesting traffic never encrypts. The peer is a Cisco ASA.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

  • Name the first CLI command to run on Palo Alto for this ticket

  • Separate the layer that is actually broken from the layer people blame

  • Apply one scoped fix instead of a global disable

  • Prove the ticket closed with a session, log, or counter

Quick answer

Phase-1 only proves IKE identity. Phase-2 dies when proxy-IDs / encryption domains do not match. Align local/remote networks, not the IKE gateway.

Why this ticket shows up

Palo Alto uses proxy-IDs. Cisco uses crypto ACLs. One extra subnet on either side keeps Quick Mode failing while Phase-1 stays up forever.

Symptoms operators actually see

  • IKE SA exists, IPsec SA count is 0

  • Tunnel interface stays empty of packets

  • Peer log says TS_UNACCEPTABLE or proxy mismatch

  • Ping from the firewall works, LAN-to-LAN does not

CLI first — copy this block

Run these on the Palo Alto device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

show vpn ike-sa gateway BRANCH-1
show vpn ipsec-sa tunnel BRANCH-1
show vpn flow
test vpn ipsec-sa tunnel BRANCH-1
show log system query equal "( description contains ike )"
show running ipsec-tunnel

How to read that output

ike-sa can be Established while ipsec-sa is empty. That is a proxy-ID problem, not a PSK problem. Compare local and remote networks to the ASA crypto ACL line by line.

Triage order

  1. Confirm Phase-1 is up with show vpn ike-sa.

  2. Confirm Phase-2 is missing with show vpn ipsec-sa.

  3. Export proxy-IDs and the peer crypto ACL.

  4. Make them identical, including /32 vs /24 mistakes.

  5. test vpn ipsec-sa and send one interesting packet from a real LAN host.

Classic traps

What you see

Real cause

Fix

Change the PSK

Phase-1 is already up

Do not touch IKE

Add 0.0.0.0/0 proxy-ID

Peer expects exact subnets

Match the crypto ACL

Ping from the firewall

Firewall source is not in the proxy-ID

Ping from a LAN host

Proof the ticket is closed

  • ipsec-sa shows SPI pairs

  • Bytes increment both ways

  • LAN host reaches the far subnet

Say this in an interview

Green Phase-1 is not a working VPN. I prove Phase-2 proxy-IDs against the peer crypto ACL.

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/

Comments


bottom of page