Proving the Path Part 5: Policy/NAT and IPsec

Part 4 confirmed the SD-WAN and SLA layer behaved correctly and had no mechanism to touch the already-established Teams session. Stage 6 and 7 of the chain, policy/NAT and IPsec, check the layer that pinned session is actually still committed to, because “SD-WAN isn’t at fault” doesn’t automatically mean “the path this session is using was fine.”

The policy the session matched

Part 2’s session entry recorded policy_id=44. Checking that policy against the live configuration is a five-second sanity check, and it comes back clean: same source and destination objects, same NAT settings, no recent change:

show firewall policy 44
config firewall policy
    edit 44
        set name "branch-teams-m365"
        set srcintf "lan"
        set dstintf "to-hub1" "to-hub2"
        set action accept
        set nat enable
        set ippool disable
    next
end

Nothing here has drifted, and nothing here needed to. The policy allows egress out either overlay member and applies interface-based NAT, which is exactly what Part 2’s session output showed in practice (act=snat, translated to the WAN-facing address). This confirms the rule the session matched is unchanged. It doesn’t yet say anything about which of the two listed interfaces the session is actually using, which is the IPsec question.

Which tunnel, and is it actually healthy

The session’s egress, per Part 2, is via to-hub1, the pinned member, chosen before the SLA breach and never re-evaluated since. The question that matters now is whether that specific tunnel’s phase 1 and phase 2 SAs were themselves in a state consistent with degraded voice quality during the incident window:

diagnose vpn tunnel list name to-hub1
    tun_id: 203.0.113.10  ike_id: 12345
    proxy id: 
      src: 0.0.0.0/0
      dst: 0.0.0.0/0
    selectors match
    sa lifetime remaining: 2841
    incoming bytes: ...  outgoing bytes: ...

The SA never dropped and the selectors are correct: there’s no phase 2 mismatch, no re-key event during the window, nothing that would show up as a hard IPsec failure. That’s consistent with everything else this series has found: nothing in the control plane broke. The tunnel’s health-check counters (the same dce-probe figures from Part 4) are the only place the actual degradation shows up, because the SLA breach was a data-plane loss and latency event, not a tunnel-down event. The tunnel being up the whole time is real, and it’s also exactly why nobody looking at tunnel state alone would have found anything wrong.

False conclusion checkpoint: the tunnel is up, so VPN is healthy

This is the clearest version of that trap in the whole series. diagnose vpn tunnel list and the phase 1/2 SA state answer “is the cryptographic association intact,” not “is the path behind it currently meeting an application’s requirements.” A tunnel can be perfectly up while carrying 2.4% packet loss, which is nothing to IKE and everything to a live voice codec. The evidence that actually mattered here was never the tunnel state; it was the health-check’s loss and jitter figures from Part 4, correlated against the session’s fixed egress interface from Part 2.

False conclusion checkpoint: a config line proves the policy matched

Policy 44’s configuration is correct and unchanged, and on its own that tells you what a session would match if evaluated now. It says nothing about what a specific session already matched, or when. The session table entry (policy_id=44, hook=post dir=org act=snat) is the only thing that proves what actually happened at runtime, and it’s worth treating the config and the session output as two separate, complementary pieces of evidence rather than assuming one implies the other.

Where this leaves us

Nothing in policy, NAT or IPsec is broken, misconfigured or currently unhealthy. The pinned session is faithfully and correctly continuing to use the same policy, NAT translation and tunnel it selected at creation: a tunnel that’s cryptographically fine but was, for a few minutes, carrying more loss than a voice call tolerates. Every stage checked so far has come back clean on its own terms. Part 6 finishes at egress and NPU offload, where the last piece of direct evidence lives, and closes out with what actually fixing this looks like.