I85PREP
⌘ K
Palo Alto SD-WAN Engineer study materials
Palo Alto SD-WAN Engineer study resources

Branch SD-WAN Tunnel Failures Behind DHCP and NAT

Palo Alto SD-WAN Engineer · Put your knowledge to work in context.

All case studies

Branch SD-WAN Tunnel Failures Behind DHCP and NAT

Your company is deploying SD-WAN to 60 retail branches. Each branch has a PA-450 HA pair and two ISP links: a 500/100 Mbps cable circuit using DHCP and a 100/100 Mbps fiber circuit with static addressing. The two HQ hubs are PA-5450 HA pairs, each with two ISP connections. Design requires an SD-WAN overlay from every branch to both hubs, with corporate traffic sent to HQ and guest traffic broken out locally. During pilot, 18 branches built tunnels; the remaining branches, all on the DHCP cable circuit, show IKE phase 1 up but no SD-WAN tunnel interface. Branches are behind ISP NAT. The branch SD-WAN interface profile is applied to Ethernet1/1 and Ethernet1/2, and both tunnels point to the same HQ public IP. The project manager wants to know whether to continue the rollout next week. You must decide what to fix before scaling.

1. Which configuration or design issues are most likely preventing SD-WAN tunnels from coming up on the DHCP/NAT branches, and how would you verify each?

Read the worked answer

Most likely causes, in order:

  1. Dynamic local address mismatch. The DHCP circuit's public address changes, but the SD-WAN tunnel or IKE gateway is bound to a static local address or an interface that does not track DHCP. The IKE SA can come up using the current address while the tunnel interface or proxy-ID uses a stale address. Verify the IKE gateway local address, the tunnel local endpoint, and the DHCP lease/default route on Ethernet1/1.
  2. NAT traversal and identity. Branches behind ISP NAT need NAT-T enabled and a consistent local/peer identification. If the HQ peer expects an IP identity but the branch presents an FQDN, phase 1 may succeed but the child SA or tunnel interface will not. Check IKE and IPsec logs, show ike-sa, show ipsec sa, and the SD-WAN tunnel monitor.
  3. Interface profile binding. The SD-WAN interface profile must be attached to the correct physical interface and zone, and the tunnel must reference that interface. Verify with show sdwan interface and tunnel details; a profile applied to a different zone or an unassigned interface will not carry SD-WAN traffic.
  4. Single HQ endpoint design. Both tunnels terminate on one HQ public IP. That can work behind an active/passive HA pair, but it gives no hub redundancy and can fail on HA failover. Use separate HQ endpoints or loopback-based endpoints advertised by BGP.

Do not scale until a DHCP branch passes a full tunnel, path-quality, and failover test.

2. How should the tunnel endpoint design change so the branch overlay survives an HQ firewall failover?

Read the worked answer

The current design has both branch tunnels pointing to one HQ public IP. If that IP is owned by the active HA node, a failover will break both tunnels even though the branch has two ISPs. The branch has link redundancy but not hub redundancy.

Change the endpoint design so each branch has at least one tunnel to each HQ firewall, or to loopback endpoints that are advertised consistently through BGP and can be reached through either HQ node. Prefer loopback-based tunnel endpoints because they do not move with HA failover. Ensure the branch has two SD-WAN tunnels with distinct peer addresses, and that routing prefers the active path while keeping the standby tunnel healthy. Validate by failing the active HQ node and confirming that branch tunnels re-establish to the standby endpoint, BGP routes reconverge, and path-quality probes resume within the required recovery time.

3. What pilot acceptance criteria would you require before approving the remaining 42 branches?

Read the worked answer

Require evidence, not just a successful ping:

  • SD-WAN tunnels up to both hub endpoints, with the correct local and peer identities.
  • Path-quality probes passing on both ISP links, and failover to the secondary ISP when the primary is impaired.
  • BGP or static routing verified in both directions, including the default route and any HQ-advertised prefixes.
  • Guest local breakout working without bypassing required security inspection.
  • HA failover test on the branch pair, with sessions and tunnels recovering.
  • Panorama push and template-stack variables validated on a DHCP branch and a static-IP branch.
  • A documented rollback and a 24-hour soak test with no unexplained tunnel flaps.

If any DHCP/NAT branch cannot meet these, keep the remaining branches on the old design until the fix is proven.