Azure's Default route-based policy negotiates which Diffie-Hellman group for IKE Phase 1?

Correct: a. Azure's Default proposes the weak DH Group 2 (1024-bit) for Phase 1 — exactly why you define a Custom IPsec/IKE policy when you want DH14 or stronger on both ends.

You want DH14 / AES-256 / SHA-256 with PFS on both ends. Where on the Azure side do you pin that?

Correct: b. Crypto is set per-Connection via a Custom IPsec/IKE policy — that's the only place to pin DH14/PFS. Address space (a), SKU (c) and subnet routes (d) don't touch the cipher suite.

Your Palo Alto is a PA-VM behind a NAT device — its real untrust IP is translated — and Phase 1 stalls. Which fix applies?

Correct: c. Behind NAT the on-wire IP no longer equals the IKE identity, so NAT-T (UDP 4500) plus explicit IDs make identity match. BGP/MTU, IKEv1 and DPD changes don't address the identity mismatch.

Small pings and SSH work across the tunnel, but large file copies and RDP hang with "fragmentation needed, DF set". The fix?

Correct: d. IPsec headers plus Azure's 1360-byte clamp shrink the usable payload; clamping MSS stops oversized segments. The classic "ping works, files don't" MTU symptom — not SKU, proxy-ID or DPD.

The tunnel drops after quiet periods and a gateway reset brings it back temporarily. Most likely cause and fix?

Correct: a. Idle teardown plus over-aggressive DPD look exactly like flaps; a tunnel monitor keeps traffic flowing so it never goes idle. A wrong PSK or mismatched Proxy ID would stop the tunnel coming up at all, not flap.

A 5,000-user production site has many Azure subnets that change monthly and needs automatic failover. Static routes or BGP over the tunnel?

Correct: d. BGP removes manual route maintenance and provides redundancy/failover at scale. Static routes don't scale or fail over; policy-based can't run BGP at all; a second PSK is irrelevant to routing.

Azure ↔ Palo Alto Site-to-Site IPsec VPN — the IKEv2 config that actually comes up

Q: You're standing up a fresh Palo Alto-to-Azure VPN. Which Azure VPN Gateway type and IKE version should you choose?

Correct: b. Palo Alto runs the tunnel as a route-based interface, so it needs Azure's route-based gateway (any-to-any selectors) and IKEv2. Policy-based is IKEv1-only / static-only; BGP is optional, not a substitute; Basic SKU can't do BGP and forces IKEv1 reconnect issues.

Q: Phase 1 shows established, but Phase 2 won't form and the firewall logs NO_PROPOSAL_CHOSEN . What is the most likely cause on a Palo Alto-to-Azure tunnel?

Correct: a. A green Phase 1 means the PSK and crypto already matched — so it isn't (b) or (c). A missing policy (d) blocks traffic on an up tunnel; it doesn't stop Phase 2 negotiating. Phase 2 = traffic selectors = Proxy IDs, and they must mirror.

Q: Azure Connection is route-based, "Use policy based traffic selector" is Disabled. What Proxy ID belongs on the Palo Alto IPSec tunnel?

Correct: c. Route-based Azure offers any-to-any (0.0.0.0/0) selectors, so the Palo Alto must mirror that exactly. Narrowed pairs (a) and explicit lists (b) belong to the policy-based path. (d) is the trap — a universal Proxy ID is the cleanest way to guarantee the mirror.

Q: IKE and IPsec SAs are both established on the Palo Alto and Azure shows "Connected", but no traffic crosses either way. What do you check first?

Correct: b. Both SAs up means crypto, PSK and selectors already agreed — so (a) and (c) are settled. SKU throughput (d) would slow traffic, not stop it dead. "Tunnel up, no traffic" is a routing/policy gap: a route into tunnel.1 plus a permitting rule.

Most engineers think…

…that once IKE Phase 1 shows "established", the hard part is over and traffic will just flow.

Wrong. Phase 1 only opens the secure hotline. Phase 2 — the proxy-ID / traffic-selector handshake — is where Azure tunnels actually die, and it fails silently behind a green Phase 1. This whole lesson lives in that gap.

① The mental model — what each side brings to the tunnel

Think of an IPsec VPN as a private armoured tunnel dug between two buildings: your office on one side, your Azure VNet on the other. Before you touch a single field, get the picture straight — because Azure and the Palo Alto describe the same tunnel with completely different vocabulary, and that mismatch is where beginners get lost.

On the Azure side you build four objects. On the Palo Alto side you build eight. They meet in the middle over the public internet.

Figure 1 — one tunnel, two mental models

The same encrypted path. The Palo Alto thinks in tunnel.1; Azure thinks in a Connection tied to a Local Network Gateway that represents your firewall.

The one decision that decides everything: pick a route-based gateway, not a policy-based one, and run IKEv2. Since October 2023 the Azure portal only creates route-based gateways anyway, so you are usually on the right side by default — but if you inherited an old policy-based gateway, the Palo Alto will never come up cleanly.

👉 So far: Azure = 4 objects (the Local Network Gateway is the Palo Alto side; the Connection is the tunnel). Palo Alto = a tunnel interface plus crypto, gateway, tunnel, route and policy. Choose route-based + IKEv2.

Priya at Flipkart faces this

She built the Azure gateway from an old runbook, picked "policy-based", and now the Palo Alto IKE Gateway sits in init forever. No errors that make sense.

Likely cause

Policy-based Azure gateways are IKEv1-only and static-routing-only. Her Palo Alto IKE Gateway is set to IKEv2 — the two never agree on a version.

Diagnosis

Check the Azure gateway's VPN type and the Palo Alto IKE version. They're on different IKE generations.

Azure: VNet Gateway → Configuration · PAN: Network → IKE Gateways → Version

Fix

Rebuild the Azure gateway as route-based (the portal default), keep the Palo Alto on IKEv2 only mode.

Verify

show vpn ike-sa gateway azure-ike-gw now shows an IKEv2 SA negotiating instead of silence.

Quick check · Q1 of 10

You're standing up a fresh Palo Alto-to-Azure VPN. Which Azure VPN Gateway type and IKE version should you choose?

a) Policy-based gateway with IKEv1 b) Route-based gateway with IKEv2 c) Either type, as long as you enable BGP d) Basic SKU with IKEv1 for the cheapest path

Correct: b. Palo Alto runs the tunnel as a route-based interface, so it needs Azure's route-based gateway (any-to-any selectors) and IKEv2. Policy-based is IKEv1-only / static-only; BGP is optional, not a substitute; Basic SKU can't do BGP and forces IKEv1 reconnect issues.

② Phase 1 vs Phase 2 — where tunnels actually die

Here is the single most useful analogy for IPsec. Picture two embassies opening a secure hotline.

Phase 1 is the two embassies agreeing how to talk: they check each other's credentials (the PSK), pick a shared cipher and key-exchange group, and open the encrypted channel. In firewall terms this is the IKE SA.

Phase 2 is the embassies agreeing which citizens may cross — which subnets are allowed through the channel. Palo Alto calls this list a Proxy ID; the IKE spec (and Azure) call it a traffic selector. If the two sides don't describe the guest list as exact mirror images, Phase 2 fails — even though Phase 1 looked perfectly healthy.

See it come up — then watch it die

Press Play to step through a healthy bring-up, then Break it to see the failure most real tickets are about.

▶ How a Palo Alto ⇄ Azure tunnel negotiates

Four stages. Press Play for the healthy path, then Break it to see the classic Phase-2 failure.

① IKE Phase 1 — agree HOW to talkPAN (203.0.113.10) and Azure (20.55.10.20) prove identity with the PSK and agree DH14 / AES-256 / SHA-256. The IKE SA — the secure hotline — comes up.

▼

② IKE Phase 2 — agree the guest listBoth sides propose traffic selectors. PAN offers 0.0.0.0/0 ↔ 0.0.0.0/0; Azure (route-based) offers the same. They mirror → an ESP IPsec SA is installed.

▼

③ Route + policy — give the tunnel a jobA static route sends 10.20.0.0/16 into tunnel.1, and a security rule allows trust ⇄ azure-vpn both ways.

▼

④ Traffic flowsA host in Mumbai HQ (10.10.0.0/16) reaches an Azure VM at 10.20.0.4 — encrypted end to end.

Press Play to step through the healthy path. Then press Break it.

Figure 2 — Phase 1 builds the channel; Phase 2 is where it dies

The trap: monitoring shows Phase 1 "established", so it looks healthy — but Phase 2 (the proxy-ID handshake) never completed, so not a single packet crosses.

The four words you must own

Tap each card. These four ideas carry the whole lesson.

🤝

IKE Phase 1

tap to flip

Peers authenticate with the PSK and agree encryption + DH group, building the secure IKE SA. So what: if it fails you see only "phase-1 negotiation failed" — start with PSK and IKE version.

📋

Proxy ID

tap to flip

The local/remote subnet pair PAN proposes in Phase 2 — the IKE "traffic selector". So what: it must mirror Azure's offer exactly, or Phase 2 dies while Phase 1 stays green.

🧭

Route-based

tap to flip

Azure gateway that uses any-to-any (0.0.0.0/0) selectors and routes traffic into the tunnel. So what: this is the mode Palo Alto expects — match it with a 0.0.0.0/0 proxy-ID.

🚇

tunnel.1

tap to flip

A logical Palo Alto interface in its own zone; routes point traffic into it. So what: no static route to tunnel.1 = the tunnel is "up" but zero traffic crosses.

Pause & Predict

Your tunnel shows Phase 1 established but Phase 2 won't come up and the log says NO_PROPOSAL_CHOSEN. Before you read on — name the one object that is almost always the cause. Type your guess.

Answer: The Proxy ID (traffic selector). Phase 1 already proved identity and crypto matched — the only thing left in Phase 2 is the subnet guest-list, and it isn't mirroring Azure's 0.0.0.0/0 offer.

Aditya at Wipro faces this

His tunnel worked yesterday. Today a teammate "cleaned up" the config. Now Phase 1 is green, but show vpn ipsec-sa is empty and the log repeats IKE phase-2 negotiation is failed ... NO_PROPOSAL_CHOSEN.

Likely cause

The teammate narrowed the Palo Alto Proxy ID to 10.10.0.0/16 ↔ 10.20.0.0/16 "to be tidy". Azure (route-based) still offers 0.0.0.0/0 ↔ 0.0.0.0/0. The selectors no longer mirror.

Diagnosis

Phase 1 SA present, Phase 2 absent = a traffic-selector mismatch, not a crypto or PSK problem.

Network → IPSec Tunnels → azure-ipsec-tunnel → Proxy IDs

Fix

Set the Proxy ID back to Local 0.0.0.0/0, Remote 0.0.0.0/0 (or delete it so PAN proposes the universal selector). Commit.

Verify

test vpn ipsec-sa tunnel azure-ipsec-tunnel then show vpn ipsec-sa — the ESP SA now appears.

Quick check · Q2 of 10

Phase 1 shows established, but Phase 2 won't form and the firewall logs NO_PROPOSAL_CHOSEN. What is the most likely cause on a Palo Alto-to-Azure tunnel?

a) The Proxy ID / traffic selectors don't mirror between PAN and Azure b) The pre-shared key is wrong c) The public IP of the gateway changed d) The security policy is missing

Correct: a. A green Phase 1 means the PSK and crypto already matched — so it isn't (b) or (c). A missing policy (d) blocks traffic on an up tunnel; it doesn't stop Phase 2 negotiating. Phase 2 = traffic selectors = Proxy IDs, and they must mirror.

👉 So far: Phase 1 = "how we talk" (PSK + crypto → IKE SA). Phase 2 = "who may cross" (Proxy IDs). A green Phase 1 with a dead Phase 2 is almost always a Proxy-ID mismatch.

③ Build it — Azure side, then Palo Alto side

Now the hands-on. We'll use one topology throughout: on-prem LAN 10.10.0.0/16 behind a Palo Alto with untrust IP 203.0.113.10, talking to an Azure VNet 10.20.0.0/16 fronted by a VPN Gateway at 20.55.10.20.

Azure side — four objects

Create the Virtual Network Gateway (route-based, SKU VpnGw2AZ, in a subnet named exactly GatewaySubnet, /27 or larger), a Standard Static Public IP, a Local Network Gateway for the Palo Alto, then the Connection. The Connection blade is where the tunnel is actually defined:

🖥️ This is the screen you'll use — Virtual network gateway → Connections → + Add in the Azure portal. (Recreated for clarity — your portal matches this layout.)

portal.azure.com · Add connection

NameVNet-to-PaloAlto

Connection typeSite-to-site (IPsec)①

Virtual network gatewayvnetgw-prod-01

Local network gatewaylng-paloalto-hq

Shared key (PSK)S2sVpnAzure!Psk#2026②

IKE ProtocolIKEv2③

Use policy based traffic selectorDisable

IPsec / IKE policyDefault

DPD timeout in seconds45

Review + create

① Connection type = Site-to-site (IPsec). ② Shared key must byte-match the Palo Alto PSK. ③ IKE Protocol = IKEv2 for route-based. Leave Use policy based traffic selector = Disable for a normal route-based Palo Alto.

Azure — PowerShell (Local Network Gateway + Connection)

New-AzLocalNetworkGateway -Name lng-paloalto-hq -ResourceGroupName rg-net `
  -Location "Central India" `
  -GatewayIpAddress "203.0.113.10" `
  -AddressPrefix "10.10.0.0/16"

$gw  = Get-AzVirtualNetworkGateway -Name vnetgw-prod-01 -ResourceGroupName rg-net
$lng = Get-AzLocalNetworkGateway   -Name lng-paloalto-hq -ResourceGroupName rg-net

New-AzVirtualNetworkGatewayConnection -Name VNet-to-PaloAlto -ResourceGroupName rg-net `
  -Location "Central India" `
  -VirtualNetworkGateway1 $gw -LocalNetworkGateway2 $lng `
  -ConnectionType IPsec -SharedKey "S2sVpnAzure!Psk#2026"

Expected output

Name              : VNet-to-PaloAlto
ResourceGroupName : rg-net
ConnectionType    : IPsec
ConnectionStatus  : Unknown        # becomes "Connected" once the Palo Alto side is up
ProvisioningState : Succeeded

Palo Alto side — the eight objects

Build them in order: tunnel interface → IKE Crypto → IPSec Crypto → IKE Gateway → IPSec Tunnel → zone → static route → security policy. The two screens that trip people up are the IKE Gateway and the IPSec Tunnel's Proxy ID tab.

🖥️ The screen that saves the tunnel — Network → IPSec Tunnels → Add, then the Proxy IDs tab. (Recreated for clarity — your PAN-OS console matches this.)

PA-VM · Network ▸ IPSec Tunnels ▸ azure-ipsec-tunnel

Nameazure-ipsec-tunnel

Tunnel Interfacetunnel.1②

TypeAuto Key

IKE Gatewayazure-ike-gw

IPSec Crypto Profileazure-ipsec-crypto

Proxy IDs ▸ Local0.0.0.0/0①

Proxy IDs ▸ Remote0.0.0.0/0①

① The Proxy ID Local 0.0.0.0/0 ↔ Remote 0.0.0.0/0 is the field that mirrors Azure's route-based offer — get this right and Phase 2 installs. ② Tunnel Interface must be the tunnel.1 you created and put in the azure-vpn zone.

Palo Alto — set commands (crypto, gateway, tunnel, route, policy)

set network ike crypto-profiles ike-crypto-profiles azure-ike-crypto dh-group group14 hash sha256 encryption aes-256-cbc lifetime hours 8
set network ike crypto-profiles ipsec-crypto-profiles azure-ipsec-crypto esp encryption aes-256-cbc esp authentication sha256
set network ike crypto-profiles ipsec-crypto-profiles azure-ipsec-crypto dh-group no-pfs lifetime hours 1

set network ike gateway azure-ike-gw protocol version ikev2
set network ike gateway azure-ike-gw protocol ikev2 ike-crypto-profile azure-ike-crypto dpd enable yes
set network ike gateway azure-ike-gw authentication pre-shared-key key S2sVpnAzure!Psk#2026
set network ike gateway azure-ike-gw local-address interface ethernet1/1 ip 203.0.113.10/24
set network ike gateway azure-ike-gw peer-address ip 20.55.10.20
set network ike gateway azure-ike-gw protocol-common nat-traversal enable yes

set network tunnel ipsec azure-ipsec-tunnel auto-key ike-gateway azure-ike-gw
set network tunnel ipsec azure-ipsec-tunnel auto-key ipsec-crypto-profile azure-ipsec-crypto
set network tunnel ipsec azure-ipsec-tunnel tunnel-interface tunnel.1
set network tunnel ipsec azure-ipsec-tunnel auto-key proxy-id azure-any local 0.0.0.0/0 remote 0.0.0.0/0 protocol any

set zone azure-vpn network layer3 tunnel.1
set network virtual-router default routing-table ip static-route to-azure-vnet destination 10.20.0.0/16 interface tunnel.1
set rulebase security rules trust-to-azure from trust to azure-vpn source 10.10.0.0/16 destination 10.20.0.0/16 application any service application-default action allow
commit

Expected output

Commit job 421 ... 100%
Configuration committed successfully

Figure 3 — the proxy-ID decision (the one that decides if Phase 2 lives)

Leave Azure's traffic selector disabled and use a single 0.0.0.0/0 proxy-ID. Enabling the policy-based selector forces you to list every subnet pair by hand.

💡 Pro Tip — match crypto on purpose

Azure's Default policy negotiates a weak DH Group 2 (1024-bit) for Phase 1. To run DH14 / AES-256 / SHA-256 like our config, define a Custom IPsec/IKE policy on the Azure Connection so both ends use the same strong set. Set it once on each side and it matches — half-matching just drops the tunnel at the first rekey.

⚠ Common Mistake — the PSK with an invisible space

Copy-pasting the Azure Shared key often drags a trailing space or newline into the Palo Alto PSK field. Phase 1 then fails with "authentication failed" and you swear they're identical. Re-type the key by hand on both ends.

Pause & Predict

Your Azure Connection is route-based and left at the Default policy. What exact Proxy ID should the Palo Alto IPSec Tunnel carry? Type it.

Answer: Local 0.0.0.0/0 ↔ Remote 0.0.0.0/0. Route-based Azure negotiates any-to-any selectors, so the Palo Alto must mirror that with a single universal proxy-ID.

Rahul at TCS faces this

Brand-new build. Phase 1 won't even start — IKE phase-1 negotiation is failed ... no proposal chosen — and he's triple-checked the PSK.

Likely cause

Crypto mismatch: he set DH14 on the Palo Alto but left the Azure Connection on the Default policy, which proposes DH Group 2 for Phase 1. They never agree.

Diagnosis

"No proposal chosen" in Phase 1 = the encryption/DH/hash sets don't overlap.

PAN: Network → IKE Crypto · Azure: Connection → Configuration → IPsec/IKE policy

Fix

Define a matching Custom IPsec/IKE policy on the Azure Connection (DH14 / AES-256 / SHA-256), or drop the Palo Alto to DH2 to match Default. Make both ends identical.

Verify

show vpn ike-sa gateway azure-ike-gw shows an SA moving past the proposal stage.

Quick check · Q3 of 10

Azure Connection is route-based, "Use policy based traffic selector" is Disabled. What Proxy ID belongs on the Palo Alto IPSec tunnel?

a) Local 10.10.0.0/16 ↔ Remote 10.20.0.0/16 b) One Proxy ID per Azure subnet, listed explicitly c) Local 0.0.0.0/0 ↔ Remote 0.0.0.0/0 d) No Proxy ID is ever needed for route-based

Correct: c. Route-based Azure offers any-to-any (0.0.0.0/0) selectors, so the Palo Alto must mirror that exactly. Narrowed pairs (a) and explicit lists (b) belong to the policy-based path. (d) is the trap — a universal Proxy ID is the cleanest way to guarantee the mirror.

👉 So far: Azure = Connection (Site-to-site, IKEv2, matching PSK). Palo Alto = crypto + IKE gateway + IPSec tunnel with a 0.0.0.0/0 proxy-ID + zone + static route + policy. Crypto must match on purpose.

④ Verify & troubleshoot — prove it from the logs

Never trust the config screen — trust the runtime. Three commands tell you the truth, in order: is Phase 1 up, is Phase 2 up, is the datapath active.

Palo Alto — verification (run top to bottom)

> show vpn ike-sa gateway azure-ike-gw
> show vpn ipsec-sa
> show vpn flow

Expected output (healthy tunnel)

# Phase 1
GwID  Gateway Name   Role  Mode   Algorithm                Established  ST
1     azure-ike-gw   Init  IKEv2  PSK/DH14/A256/SHA256      yes          Estb

# Phase 2
GwID  Tunnel              Algorithm        SPI(in)   SPI(out)  life  remain
1     azure-ipsec-tunnel  ESP/A256/SHA256  0xC1A2B3  0xD4E5F6  3600  3540

# Datapath
id  name                state   monitor  local-ip      peer-ip      tunnel-i/f
1   azure-ipsec-tunnel  active  up       203.0.113.10  20.55.10.20  tunnel.1

✅ Prove it from the runtime, not the GUI

A saved config is a promise; show vpn ipsec-sa is the proof. If Phase 1 shows Estb but show vpn ipsec-sa is empty → Phase 2 / Proxy ID. If both SAs exist but nothing pings → routing and policy, not crypto.

That second case — tunnel up, no traffic — is the quiet killer. Proxy IDs only negotiate the SA; they never create a data path. You still need the static route into tunnel.1 and a security rule. And once real apps run, the Palo Alto must clamp MSS: Microsoft recommends MSS 1350 / tunnel MTU 1400 because IPsec headers plus Azure's 1360-byte clamp shrink the usable payload.

Pause & Predict

Both show vpn ike-sa and show vpn ipsec-sa are healthy, but nothing pings across. Is this a crypto problem or a routing problem? Type your call.

Answer: Routing. Both SAs are up, so crypto and selectors already agreed. The missing piece is the static route to 10.20.0.0/16 via tunnel.1 and a security policy allowing trust ⇄ azure-vpn.

Sneha at Infosys faces this

All three status lights are green. IKE + IPsec SAs are up. Yet ping to the Azure VM times out, both directions, and packet capture shows nothing arriving from the far side.

Likely cause

No static route points 10.20.0.0/16 at tunnel.1, so the firewall has no reason to send VNet traffic into the tunnel — or tunnel.1 was never put in a zone with a permitting rule.

Diagnosis

SAs up + zero traffic = routing/policy, not crypto. Check the route table and the security rulebase.

Network → Virtual Routers → default → Static Routes · Policies → Security

Fix

Add the static route 10.20.0.0/16 → tunnel.1, bind tunnel.1 to zone azure-vpn, and add bidirectional security rules. On Azure, confirm the Local Network Gateway lists 10.10.0.0/16.

Verify

test routing fib-lookup virtual-router default ip 10.20.0.4 resolves out tunnel.1, then ping succeeds.

Figure 4 — the one-page cheat-sheet

Screenshot this one before an interview or a maintenance window — it's the whole lesson on a single card.

Practice in the Palo Alto IPSec Simulator

⚠ Three more real-world traps

Flaps after idle: Azure tears down an idle tunnel after ~5 minutes and DPD defaults to 45s — add a Tunnel Monitor so the tunnel never goes quiet. PAN behind NAT (a PA-VM with a NAT'd untrust IP): enable NAT Traversal and set explicit Local/Peer Identification. Many changing subnets at scale: stop hand-editing static routes — run BGP over the tunnel for auto-advertised prefixes and HA.

Quick check · Q4 of 10

IKE and IPsec SAs are both established on the Palo Alto and Azure shows "Connected", but no traffic crosses either way. What do you check first?

a) The pre-shared key and DH group b) The static route to the VNet via tunnel.1 and the security policy c) The IKE version on the Azure connection d) The gateway SKU throughput limit

Correct: b. Both SAs up means crypto, PSK and selectors already agreed — so (a) and (c) are settled. SKU throughput (d) would slow traffic, not stop it dead. "Tunnel up, no traffic" is a routing/policy gap: a route into tunnel.1 plus a permitting rule.

🛡 Keep current — and where this is tested

The site-to-site IPsec engine has been quiet, but the wider PAN-OS VPN surface hasn't — keep firmware patched against issues like the actively-exploited GlobalProtect auth-bypass CVE-2026-0257 (CVSS 7.8) and the infamous CVE-2024-3400 (CVSS 10.0). On the exam side this is a two-cert crossover: the firewall half maps to Palo Alto's Network Security Generalist / NGFW Engineer (the role-based successors to the retired PCNSE), and the cloud half is squarely on Microsoft AZ-700.

👉 So far: verify from show vpn ike-sa / ipsec-sa / flow. SAs up + no traffic = routing. Clamp MSS to 1350. Keep a tunnel monitor so Azure doesn't drop an idle tunnel.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Palo Alto docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: Why does a route-based Azure VPN tunnel need a 0.0.0.0/0 ↔ 0.0.0.0/0 Proxy ID on the Palo Alto? Then compare to the expert version.

Expert version: Azure's route-based gateway negotiates any-to-any IKE traffic selectors (0.0.0.0/0). PAN-OS expresses traffic selectors as Proxy IDs, so to mirror Azure's offer the Palo Alto must propose the same universal 0.0.0.0/0 ↔ 0.0.0.0/0 — otherwise Phase 2 throws NO_PROPOSAL_CHOSEN even though Phase 1 is established.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Azure Site-to-Site VPN at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

IKE / ISAKMP: The protocol that authenticates the two gateways and builds the secure key-exchange channel.
IKE Phase 1: Authenticates peers with the PSK and agrees encryption + DH group, building the IKE SA (the management channel).
IKE Phase 2 (Quick Mode): Negotiates the traffic selectors / proxy-IDs and installs the ESP data SA.
Proxy ID: Palo Alto's name for the local/remote subnet pair a tunnel will encrypt — the IKE traffic selector.
Traffic selector: The source/destination network pair negotiated in Phase 2 that defines which traffic the SA protects.
Route-based VPN: An Azure gateway that uses any-to-any (0.0.0.0/0) selectors and routes traffic into the tunnel; needs IKEv2.
Policy-based VPN: An older Azure gateway that defines crypto per subnet pair — IKEv1-only and static-routing-only.
Local Network Gateway: The Azure object that represents the on-prem / Palo Alto side — its public IP plus the on-prem CIDRs.
Connection (Azure): The Azure object that binds the two gateways with the PSK and IKE settings — this is the tunnel.
DH group: Diffie-Hellman group — the key-exchange strength. Azure Default = Group 2; recommended = Group 14 or higher.
PFS: Perfect Forward Secrecy — a fresh DH exchange per Phase 2 rekey. Must match on both ends or the tunnel drops.
DPD: Dead Peer Detection — keepalives that spot a dead tunnel. Azure's default timeout is 45 seconds.
NAT-T: NAT Traversal — wraps IKE/ESP in UDP 4500 so the tunnel works when a peer sits behind NAT.
MSS clamping: Lowering TCP's max segment size (~1350) so packets fit the tunnel without fragmenting.
tunnel.1: The logical Palo Alto interface that terminates the tunnel; routes point traffic into it.

📚 Sources

Microsoft Learn — About VPN devices and IPsec/IKE parameters for site-to-site VPN gateway connections (default RouteBased policy, DH Group 2, P2 SA 27,000s). learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-devices
Microsoft Learn — About cryptographic requirements and Azure VPN gateways (Custom IPsec/IKE policy matrix, DPD 45s, IKE Main-Mode SA 28,800s). learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-compliance-crypto
Microsoft Learn — About VPN Gateway configuration settings (route-based vs policy-based, SKU/IKE table, GatewaySubnet /27). learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings
Microsoft Learn — Tutorial: Create a site-to-site VPN connection in the Azure portal (Local network gateway + Connection blade fields). learn.microsoft.com/azure/vpn-gateway/tutorial-site-to-site-portal
Palo Alto Networks — Set Up an IKE Gateway + Set Up an IPSec Tunnel (General/Advanced tab fields, Proxy IDs). docs.paloaltonetworks.com/network-security/ipsec-vpn
Palo Alto Networks — Define IKE Crypto Profiles & Define IPSec Crypto Profiles (PAN-OS 11.0; key-lifetime defaults). docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/vpns
Palo Alto Networks KB — How to Configure IPSec VPN to Azure (the vendor PAN ↔ Azure walkthrough Microsoft links). knowledgebase.paloaltonetworks.com
Palo Alto LIVEcommunity — Site-to-site VPN IPsec issue between PA and Azure + VPN drops after 1 minute: ike-nego-p2-proxy-id-bad (real proxy-ID failures). live.paloaltonetworks.com
Microsoft Q&A + Learn — IPsec tunnel from on-prem Palo Alto to Azure VPN Gateway (tunnel-up-no-traffic) and the AZ-700 study guide (site-to-site VPN objective). learn.microsoft.com/credentials/certifications/resources/study-guides/az-700

What's next?

You can build the tunnel — now make the routes smart. A single static route is fine for one VNet, but production hybrid networks run BGP so new Azure subnets show up automatically. Next we make routing dynamic on the Palo Alto.

Next · Palo Alto Routing — Static, OSPF & BGP → Practice on exam.techclick.in →

Azure ↔ Palo Alto Site-to-Site IPsec VPN — configure it so Phase 2 doesn't fail

🎯 By the end you will be able to

Pick where you want to start

The mental model

Phase 1 vs Phase 2

Build it, both sides

Verify & fix

① The mental model — what each side brings to the tunnel

② Phase 1 vs Phase 2 — where tunnels actually die

See it come up — then watch it die

▶ How a Palo Alto ⇄ Azure tunnel negotiates

The four words you must own

③ Build it — Azure side, then Palo Alto side

Azure side — four objects

Palo Alto side — the eight objects

④ Verify & troubleshoot — prove it from the logs

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?