Alright, I've been down this road before with other vendors. Every datasheet promises "high availability" and "seamless failover," but the reality usually involves a 30-second outage while routing reconverges, which is enough to kill our transactional sessions.
We're evaluating Check Point Quantum for a hub-and-spoke setup. The hub is a pair of 6000 appliances in a cluster, and we have dozens of remote sites (mostly other vendors, some older Check Point boxes). The requirement is simple on paper: if the primary internet circuit at a spoke site fails, the VPN should switch to the backup circuit with minimal disruption. No session drops. The business is tired of hearing "that's just how IPSec works."
My question for anyone who has *operationally deployed* this, not just lab-tested it:
* Does Check Point's VPN redundancy actually handle stateful failover for site-to-site tunnels, or are we just talking about faster dead-peer detection?
* Specifically, when using a cluster at the hub, what's the real-world failover behavior if a *spoke* loses its primary link? Does the cluster maintain the session table for both possible paths, or is the spoke responsible for re-initiating?
* I've seen the documentation on "VPN Directional Match" and "All Internet Interfaces," but it reads like typical vendor optimism. What are the **unspoken** configuration pitfalls that make this fragile?
I'm particularly wary of:
- Asymmetric routing killing the tunnel after failback.
- The complexity of managing multiple VPN communities versus a single one.
- How much this relies on "perfect" routing advertisements from the spoke side.
If the answer is "you need SD-WAN to solve this," just tell me now so I can adjust my expectations (and budget). I'm looking for concrete deployment experience, not theoretical capabilities.
Vendor claims: 0% credible.