TTechclick All lessons
Palo Alto · NGFW VPN · Site-to-SiteInteractive · L2 / L3

Palo Alto IPSec S2S — Watch a Tunnel Come Up & Find Out Why Yours Doesn't

IKEv1 vs IKEv2. Phase 1, Phase 2, proxy-ID. AWS and Azure. DPD. Route-based vs policy-based. Pick a path, press Play on the IKE animator, and walk away knowing exactly where your tunnel's broken.

📅 2026-05-25 · ⏱ 12 min · 2 live demos + lab simulator · 🏷 10-Q assessment + AI Tutor inline

Pick your path — jump straight in

1

IKE Phase 1 & 2

Main vs aggressive, DH, the Child SA — watch the SA come up.

 2

Proxy-ID & AWS / Azure

The #1 reason your tunnel comes up but no traffic flows.

 3

Route-based vs Policy

PAN-OS is route-based. Your peer might not be. Here's the fix.

 4

DPD, NAT-T, Monitoring

Liveness checks, the DPD "not persistent" trap, NAT-T over UDP 4500.

① IKE Phase 1 + Phase 2 — what actually happens before your packet flows

IPSec uses a two-phase handshake. Phase 1 (IKE SA) establishes a secure control channel between the two endpoints — they authenticate each other and agree on encryption / hashing. Phase 2 (Child SA in IKEv2 / Quick Mode in IKEv1) negotiates the actual data-plane SAs that encrypt user traffic. Phase 1 protects Phase 2; Phase 2 protects your data.

The two-phase split is why "tunnel half-up" is such a common state — Phase 1 succeeds because the IKE peers can negotiate auth and crypto, but Phase 2 fails because the proxy-IDs (the IP networks declared on each side) don't match. The IKE SA shows established; show vpn ipsec-sa shows nothing. Half-up. Frustrating.

🔐
Phase 1 — IKE SA
tap to flip

Negotiates encryption, hash, DH group, auth method, lifetime. Builds the secure control channel. IKEv1: main mode (6 packets) or aggressive (3); IKEv2: 4 packets total. UDP 500 (or 4500 with NAT-T).

📦
Phase 2 — Child SA
tap to flip

Negotiates ESP encryption + auth for actual user data. Match proxy-IDs (local + remote subnet IDs). Two SAs per tunnel — one each direction. Both peers must agree.

🆚
IKEv1 vs IKEv2
tap to flip

IKEv2 is faster (4 packets), more reliable, supports built-in DPD (Liveness Check), MOBIKE for mobile peers, EAP. Azure REQUIRES IKEv2 for route-based VPN. Default to IKEv2 in 2026; IKEv1 only for legacy peers that don't support it.

⏰
SA Lifetime & Rekey
tap to flip

Phase 1 default: 8 hrs. Phase 2 default: 1 hr (or volume-based). At ~80–90% of lifetime, the peer triggers a rekey. Mismatched lifetimes → periodic minute-long outages every hour. Match them on both sides.

Watch IKEv2 establish a tunnel — 4 packets, two SAs

▶ IKEv2 Phase 1 + Phase 2 timeline

Press Play. Sneha at Infosys is configuring a new tunnel from PA-3220 (HQ Mumbai) to PA-440 (branch Bengaluru). Watch the IKE conversation.

① IKE_SA_INIT REQ HQ → Branch · sends supported DH groups, encryption, hash, nonces over UDP 500
If NAT detected mid-path, both peers switch to UDP 4500 (NAT-T).
▼
② IKE_SA_INIT RESP Branch → HQ · agrees on common crypto, sends its DH share + nonce
If no common DH group / encryption → Phase 1 fails here. "no proposal chosen" in logs.
▼
③ IKE_AUTH REQ HQ → Branch · encrypted with new Phase-1 key · authenticates (PSK or cert) · proposes first Child SA + proxy-IDs
▼
④ IKE_AUTH RESP Branch → HQ · verifies auth · creates Child SA pair (one each direction) · proxy-IDs locked in
Phase 1 complete (IKE SA) + Phase 2 complete (1st Child SA) — all in 4 packets total.
▼
⑤ TRAFFIC FLOWS User packet from HQ LAN routed to tunnel.1 · ESP encrypted with Child SA key · sent to branch public IP
Route-based: a static route pointing to tunnel.1 triggers encryption.
▼
⑥ REKEY At ~80% of Phase-2 lifetime (default ~48 min for 1-hour SA) the responder triggers a CREATE_CHILD_SA exchange to replace keys
Smooth, in-flight rekey. Old SA expires after the new one is in use. No user-visible drop if peers agree on lifetime.
Press Play to watch the full IKEv2 4-packet handshake plus rekey. Next steps one stage.

Want to fire IKE packets yourself?

The Techclick IPSec Simulator lets you build a PA-side tunnel config, mismatch a setting on purpose, and see exactly which phase fails — without touching prod.

Open simulator →
Quick check · Q1 of 10

Sneha at Infosys configures IKEv2 between HQ and branch. The IKE SA shows established. show vpn ipsec-sa is empty. Pings across the tunnel fail. What is happening at the protocol level?

Correct: c. "IKE up, IPSec-SA empty" is the textbook half-up state. Phase 1 negotiates the control channel (auth + crypto), Phase 2 negotiates the data-plane Child SAs. If Phase 2 fails, the control channel is fine but no user packet can encrypt. The single most common cause is proxy-ID mismatch — covered in the next section.

② Proxy-ID — the AWS / Azure killer

Palo Alto runs route-based VPN by default: if a packet's destination matches a route pointing to the tunnel interface, encrypt and send. Most third-party peers (Cisco ASA, AWS site-to-site VPN, Azure VNG, SonicWall, Juniper SRX in policy mode) run policy-based VPN: encrypt only packets matching a specific (local-subnet, remote-subnet) pair declared at IKE time. That pair is called the proxy-ID.

When a PA peers with AWS/Azure, the PA silently proposes proxy-ID = (0.0.0.0/0, 0.0.0.0/0) because it's route-based and doesn't care. AWS/Azure rejects this — they want explicit subnet pairs like (10.10.0.0/16, 172.16.0.0/16). Phase 2 fails. IKE SA shows up. No traffic. Welcome to 4 hours of misery if you've never seen this before.

▶ Proxy-ID mismatch — PA ↔ AWS scenario

Rahul at TCS connects on-prem PA to AWS VPN Gateway. Default proxy-ID = any-any. AWS expects specific subnets. Watch where it breaks.

① PHASE 1 OK IKE_SA_INIT + IKE_AUTH succeed · auth verified · IKE SA established
show vpn ike-sa says state=Mature.
▼
② PA PROPOSES PA sends Phase-2 proposal with proxy-ID = (0.0.0.0/0, 0.0.0.0/0) — its default route-based behaviour
PA's view: "I have a route to AWS via tunnel.1, encrypt whatever the FIB sends here, no need for specific IDs."
▼
③ AWS REJECTS AWS VPN Gateway expects proxy-ID = (10.10.0.0/16, 172.16.0.0/16) (on-prem ↔ VPC). Any-any doesn't match.
AWS logs: "Phase 2 negotiation failed - no matching SA proposal".
▼
④ PA SEES In PA logs: cannot find matching phase-2 tunnel for received proxy ID
Half-up. show vpn ipsec-sa shows nothing. No traffic.
▼
⑤ FIX — ADD PROXY-ID Network → IPSec Tunnels → Proxy-IDs tab → add (local=10.10.0.0/16, remote=172.16.0.0/16, protocol=any)
Now PA proposes the explicit pair AWS expects. Match.
▼
⑥ COMMIT & RETRIGGER Commit · clear vpn ike-sa gateway AWS · test vpn ipsec-sa tunnel AWS · Child SA forms · traffic flows
For multi-subnet AWS VPCs, create one proxy-ID per (local, remote) subnet pair — AWS demands explicit listing.
Press Play to see why your tunnel-to-AWS won't form on first try.
Proxy-ID — the explicit-list rule for cloud VPNs

For PA ↔ AWS Site-to-Site VPN, Azure VPN Gateway, GCP Cloud VPN — always set explicit Proxy-IDs matching the exact local-subnet ↔ remote-subnet pairs. One proxy-ID per pair. Don't rely on the default 0.0.0.0/0. Azure additionally requires IKEv2 for route-based VPN. AWS supports both IKEv1 and IKEv2; pick IKEv2 for new builds. The error "cannot find matching phase-2 tunnel for received proxy ID" in PA system logs is the dead giveaway.

Quick check · Q2 of 10

Priya at HCL configures a tunnel PA ↔ Azure VPN Gateway for VNets 10.20.0.0/16 ↔ 192.168.50.0/24. She leaves proxy-IDs at the PA default. IKE SA establishes, IPSec-SA is empty. What is the single fix?

Correct: a. Azure VPN Gateway (and AWS Site-to-Site VPN) negotiates Phase 2 with explicit proxy-IDs. PA's default proxy-ID = 0.0.0.0/0 doesn't match what cloud peers expect. Add explicit proxy-IDs matching the actual (local, remote) subnet pair. Then clear the IKE SA so Phase 1+2 renegotiate. NAT-T/DPD/IKEv1 are unrelated; the failure mode is specifically about proxy-ID mismatch at Phase-2 negotiation time.

③ Route-based vs Policy-based — the architectural choice

Two ways to decide which packets get encrypted:

🛣
Route-based
tap

PA's native mode. A static or dynamic route points to a tunnel interface. Whatever the FIB sends to that tunnel gets encrypted. Scales cleanly — to add a remote subnet, add a route.

📜
Policy-based
tap

Pre-declared subnet pairs (proxy-IDs) decide what gets encrypted. No tunnel interface routing — IKE itself enforces the matching. Cisco ASA crypto-maps, AWS Site-to-Site VPN, Azure work this way.

🔧
Mixed peers
tap

PA stays route-based; the proxy-ID tab lets you "lie" about being policy-based for the peer's sake. Configure proxy-IDs that match the policy-based peer's expectations, while internally PA still routes via tunnel interface.

🆎
BGP over tunnel
tap

Run BGP over the tunnel.1 interface — the remote subnets are learned dynamically, no static-route maintenance, no proxy-ID per subnet (use 0.0.0.0/0 with peers that accept it). Standard for SD-WAN / multi-site.

CLI — read your tunnel state in 3 commands 
show vpn ike-sa
show vpn ipsec-sa
show vpn flow
Expected output (ike-sa fragment) 
GwName: Branch-Bengaluru-GW   PeerIP: 198.51.100.42
Cookie:f6a3a7c... PeerCookie:8a2f04b...
Auth: PSK   Hash: sha256   Encr: aes-256-cbc   DH: group14
Lifetime: 28800 sec    State: Mature
Quick check · Q3 of 10

A team needs PA at HQ to peer with a Cisco ASA branch running policy-based VPN. They configure PA in route-based mode with a static route 10.99.0.0/16 → tunnel.5. The ASA side has crypto-map ACL matching 10.10.0.0/16 ↔ 10.99.0.0/16. What MUST be done on the PA side?

Correct: b. PA stays route-based internally; the Proxy-ID tab is the bridge to a policy-based peer. Add proxy-IDs that mirror the peer's crypto-map ACL, and PA will propose those exact subnet pairs during Phase 2 negotiation. There's no "switch to policy-based mode" in PAN-OS — the proxy-ID feature is the canonical interop path.

④ DPD, NAT-T, Tunnel Monitoring — keeping tunnels healthy

A tunnel that's "up" can still drop traffic if the underlying network breaks. Three tools detect that:

The "DPD not persistent" trap — every prod team hits this

Palo Alto's DPD is documented as "not persistent": it only triggers on a Phase-2 rekey event. If your Phase-2 lifetime is 1 hour, DPD only checks the peer once an hour. In between, the peer can die silently and the tunnel will look "up" until next rekey. Fix: enable Tunnel Monitoring on the tunnel interface with a sensible monitor IP and short interval. Tunnel Monitoring failure forces a re-key, which in turn fires DPD — so the combination of Tunnel Monitor + DPD produces the "always-on" liveness behaviour everyone assumes DPD alone provides.

Quick check · Q4 of 10

A tunnel comes up fine when both peers are on public IPs. After a site move, one peer ends up behind a NAT router and the tunnel fails to establish. IKE_SA_INIT requests are seen on tcpdump but no responses. What's the fix?

Correct: d. NAT-T is the standard fix when either peer sits behind NAT. PAN-OS auto-detects NAT during IKE Phase 1 and switches to UDP 4500 for both IKE + ESP. The other answers are unrelated — IKEv1 vs IKEv2 doesn't help with NAT, DH group is crypto-strength, Tunnel Monitoring is a liveness check.

⑤ The 3 commands you'll actually run when a tunnel breaks

① Where did Phase 1 / Phase 2 stop? 
show vpn ike-sa gateway <gw-name>
show vpn ipsec-sa tunnel <tunnel-name>
② Are packets entering and leaving the tunnel? 
show vpn flow
show vpn flow tunnel-id <n>
What to watch 
Encap bytes:   1,234,567   ← my side is encrypting and sending
Decap bytes:           0   ← peer side is silent / NAT/firewall is dropping ESP
③ Force re-negotiation after fixing config 
clear vpn ike-sa gateway <gw-name>
test vpn ipsec-sa tunnel <tunnel-name>
The 30-second tunnel-down triage

(1) show vpn ike-sa — Phase 1 state? If Mature → Phase 1 OK. (2) show vpn ipsec-sa — Child SA(s) present? If empty → proxy-ID or Phase-2 crypto issue. (3) show vpn flow — Encap > 0 but Decap = 0 → ESP being dropped upstream; check NAT-T + intermediate firewalls allowing UDP 4500 / ESP. Decap > 0 but Encap = 0 → local routing isn't sending traffic to the tunnel; check static route → tunnel.X exists. Solves 90% of "tunnel down" tickets in under a minute.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer.

Pre-curated from PAN-OS docs + LIVECommunity TAC threads + AWS/Azure IPSec interop docs.

📝 Wrap-up — six more

You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete.

Q5 · Apply

A new tunnel is failing at Phase 1 with the error "no proposal chosen" in system logs. Both peers run IKEv2. What's the most likely cause and the quickest fix?

Correct: a. "No proposal chosen" specifically means the two peers couldn't find a common combination of encryption + hash + DH group + lifetime in their respective IKE crypto proposals. Wrong PSK shows up as "authentication failed" later. Proxy-ID is a Phase-2 issue. NAT-T usually shows as no Phase 1 traffic at all (port blocked). The fix is a line-by-line crypto profile compare.
Q6 · Analyze

The tunnel has been up for 5 days. Then show vpn ike-sa still says Mature but show vpn ipsec-sa went empty after a 2-minute network blip. Pings across the tunnel started failing. What is happening?

Correct: c. Phase 1 and Phase 2 can outlive each other; the blip killed Phase 2 but Phase 1 survived. DPD on PAN-OS only fires on Phase-2 rekey events (the "not persistent" caveat), so without Tunnel Monitoring the firewall thinks all is well. Configure Tunnel Monitoring with an interval like 3 seconds / threshold 5 to a reliable in-tunnel destination — that forces the rekey + DPD path on detection.
Q7 · Analyze

A PA-to-AWS tunnel works for VPC subnet 172.16.1.0/24 (one proxy-ID configured). The team adds VPC subnet 172.16.2.0/24, updates routes on both sides, but traffic to .2.0/24 fails while .1.0/24 still works. What's missing?

Correct: b. AWS Site-to-Site VPN negotiates one Child SA per proxy-ID pair. Adding a new VPC subnet means adding the corresponding proxy-ID on PA. After config change, commit and clear vpn ike-sa gateway X so Phase 2 re-negotiates and creates the new Child SA. Routing on both sides is necessary but not sufficient.
Q8 · Analyze

A PA at a branch sits behind a corporate router that NATs the public IP. The tunnel forms, traffic flows. After 6 weeks the corporate router is replaced with one that defaults to blocking inbound UDP 4500. What happens to the tunnel and why?

Correct: d. Once NAT-T is negotiated, both IKE and ESP run inside UDP 4500. Block 4500 inbound on the corporate router and the encapsulated return traffic dies. Existing decapsulated SA might keep limping on local state until the next rekey when IKE itself can't re-establish. Both c and d describe the same root cause — but d states the encapsulation specifics correctly. NAT-T isn't "set and forget" — the network path must allow UDP 500 + UDP 4500 continuously.
Q9 · Evaluate

A tunnel drops every ~58 minutes for exactly ~30 seconds. Phase 1 SA shows up; Phase 2 cycles. Phase-2 lifetime on PA is 1 hour. On the peer it's 30 minutes. Which is the most likely explanation and fix?

Correct: c. Mismatched Phase-2 lifetimes cause exactly this "rekey hiccup every N minutes" symptom — one peer expects to renew on a different cadence than the other. The fix is to align lifetimes (commonly 28800 sec = 8 hr for Phase 1, 3600 sec = 1 hr for Phase 2) on both peers + agree on PFS. PCNSE asks this in question form regularly.
Q10 · Evaluate

A design needs DPD + Tunnel Monitoring + NAT-T + IKEv2 + route-based to a remote PA branch. The branch is behind NAT (corporate ISP CGNAT). The team wants 5-second tunnel-failure detection. Which combination produces the desired behaviour?

Correct: a. For fast failure detection, Tunnel Monitoring (in-tunnel ICMP) is the right tool — DPD on PAN-OS is "not persistent" and only fires on Phase-2 rekey. Pair Tunnel Monitor (interval 3, threshold 2 = ~6-sec detection) with DPD enabled (so when monitor fails, rekey + DPD jointly validate). IKEv2 + NAT-T are mandatory for the NAT'd branch. Route-based stays the right architecture choice for a PA-to-PA tunnel.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto Docs — Set Up IPSec Site-to-Site VPN (PAN-OS 11.x). docs.paloaltonetworks.com
  2. Palo Alto KB — How to Troubleshoot IPSec VPN connectivity issues. knowledgebase.paloaltonetworks.com
  3. LIVECommunity — IPSec and PROXY ID. live.paloaltonetworks.com/t5/general-topics/td-p/558227
  4. LIVECommunity — cannot find matching phase-2 tunnel for received proxy ID. td-p/530545
  5. LIVECommunity — The DPD is "not persistent" and is only triggered by a Phase 2 rekey. td-p/259864
  6. Microsoft Q&A — IPsec Tunnel from On-Prem Palo Alto to Azure VPN Gateway — Tunnel Up but No Traffic Flow. learn.microsoft.com/answers/questions/2282868
  7. AWS re:Post — Troubleshoot Site-to-Site VPN IPsec/Phase 2 failure. repost.aws/knowledge-center/vpn-tunnel-phase-2-ipsec
  8. Techclick — What is Dead Peer Detection & Tunnel Monitoring across IPSec Tunnel. techclick.in

What's next?

Next up: GlobalProtect End-to-End — Portal vs Gateway roles, internal vs external GP, HIP profile + HIP match, SAML SSO, certificate-based auth, split-tunnel design. The client-side VPN every enterprise rolled out during 2020 lockdown and still runs today.

Blog 14 · GlobalProtect → ← Recap PBF & Multi-VR