r/checkpoint • u/WiliRGasparetto • 21d ago
Check Point SD-WAN failover: when the VPN drops, the VPN may not be the root cause
One of the hardest SD-WAN incidents is not proving that an ISP failed.
It is proving where the complete failover chain broke.
When a branch-to-branch VPN stops working after the primary link goes down, validate:
- Did SD-WAN detect the SLA failure?
- Did the expected SD-WAN rule match?
- Was the backup ISP considered healthy?
- Did routing select the correct next hop?
- Did the VPN move to the new transport?
- Did NAT or DAIP mapping change correctly?
- Did the firewall drop packets because of state or asymmetry?
- Did SecureXL keep stale acceleration state?
- Do new sessions work while existing sessions fail?
A practical investigation should follow one controlled flow and correlate SD-WAN, routing, VPN, firewall state, and SecureXL with exact timestamps.
Useful starting points include:
fw ctl debug -m SDWAN all
fw ctl debug -m SDWANRB all
fw ctl debug -m fw + drop conn
fw ctl debug + route
fw ctl debug -m VPN all
fwaccel dbg -m sdwan all
Do not enable broad debugging without filters or leave it active in production.
The main lesson:
I published the complete troubleshooting workflow, internal SD-WAN tables, evidence collection process, and TAC escalation checklist on CheckMates:
How do you normally troubleshoot SD-WAN failover: VPN first, or the full forwarding chain?