3.3 Link Selection & ISP Redundancy (Probing, Route-Based VPNs with VTIs)

3.3 Link Selection & ISP Redundancy (Probing, Route-Based VPNs with VTIs)

Enterprise security gateways connected to multiple Internet Service Providers (ISPs) require robust traffic engineering and high-availability frameworks for Site-to-Site VPNs. In Check Point R82, Link Selection governs how a Security Gateway selects its local IP interface for VPN tunnel negotiation, while ISP Redundancy maintains uninterrupted internet connectivity across multiple WAN links.

Furthermore, modern network architectures are shifting from traditional Domain-Based VPNs (which rely on static encryption domain definitions) to Route-Based VPNs utilizing Virtual Tunnel Interfaces (VTIs). Route-Based VPNs integrate IPsec tunnels directly into the operating system's routing table, enabling dynamic routing protocols (BGP/OSPF) and seamless multi-path WAN failover.

---

1. Link Selection Architecture & Probing Mechanisms

When a gateway has multiple public IP addresses across several WAN interfaces, Link Selection rules determine which IP address is chosen as the source/destination for IKE negotiations and IPsec ESP encapsulation.

Link Selection Configuration Modes

Configured under Gateway Properties -> IPsec VPN -> Link Selection in SmartConsole:

1. Main IP address (Default): Always uses the gateway's primary IP address (defined on the General Properties page) for VPN negotiation.
2. Selected IP address from topology: Forces the gateway to use a specific IP address selected from its configured interface topology.
3. IP Selection per Peer: Allows specifying different local IP addresses depending on which remote VPN peer is connecting (ideal for multi-homed hub gateways serving distinct regional peers).
4. Service-based Link Selection: Selects WAN interfaces dynamically based on the IP protocol or destination port of the unencrypted packet.
5. Use Ongoing Probing (RTT / ICMP / UDP): The gateway continuously monitors all WAN links by sending active probes to target IP addresses. Link Selection dynamically routes tunnel traffic across the link exhibiting the best latency or lowest packet loss.

Link Probing Engine

When Link Probing is enabled, the Security Gateway periodically transmits probe packets across each ISP interface:

• Probe Protocols: ICMP Echo Request (Ping), UDP probes, or RTT (Round Trip Time) measurement probes.
• Target IPs: Configured probe targets (e.g., ISP Default Gateway or public DNS servers like 8.8.8.8).
• Failover Evaluation: If an interface misses a configured threshold of consecutive probes (e.g., 3 missed probes spaced 10 seconds apart), Link Selection marks that link down and migrates active VPN SAs to an alternate viable interface.

---

2. ISP Redundancy Modes: Load Sharing vs. Primary/Backup

ISP Redundancy manages multi-homed internet connections for both general firewall traffic and Site-to-Site VPN tunnels (configured under Gateway Properties -> Network Management -> ISP Redundancy).

Primary / Backup Mode

• Operation: One ISP link is designated as Primary and handles 100% of outbound traffic and VPN connections. The Backup link remains completely idle.
• Failover Mechanics: The gateway continuously probes the Primary ISP link. If the Primary link fails, the gateway updates its local routes and Link Selection bindings, activating the Backup link within seconds.
• Failback: When the Primary link recovers and successfully answers probes for a designated stability duration, traffic automatically reverts to the Primary ISP.

Load Sharing Mode

• Operation: Both (or all) ISP links are active simultaneously. Outbound internet and VPN traffic is distributed across all available links based on assigned relative weight percentages (e.g., ISP1: 60%, ISP2: 40%).
• Redundancy: If one ISP link drops, 100% of the traffic automatically saturates the remaining functional link.

---

3. Domain-Based VPNs vs. Route-Based VPNs (VTIs)

Check Point R82 supports two architectural models for determining which traffic should be encrypted over a VPN tunnel:

Domain-Based VPNs (Traditional IPsec Topology)

• Mechanism: Encryption is triggered by policy inspection against defined Encryption Domains (Network Objects/Groups assigned to gateway objects).
• Traffic Matching: When a packet matches a Security Policy rule permitting access, the firewall checks if Source IP ∈ Local Domain AND Destination IP ∈ Remote Peer Domain. If true, the packet is redirected to the VPN daemon (vpnd) for IPsec encapsulation.
• Limitations: Does not support dynamic routing protocols (BGP/OSPF) natively across tunnels. Adding a new internal subnet requires modifying Encryption Domain objects and pushing policy to all gateways.

Route-Based VPNs (Virtual Tunnel Interfaces - VTIs)

• Mechanism: Decouples encryption from static domain definitions by introducing a virtual network interface object (vti1, vti2) inside the Gaia OS kernel.
• Traffic Matching: Encryption is driven entirely by the Gaia OS Routing Table. Any IP packet routed out of a VTI interface (vtiX) is automatically encapsulated in IPsec ESP by the kernel, regardless of source/destination subnets.
• Advantages: Supports BGP, OSPF, and PBR (Policy Based Routing). Simplifies network expansions—new subnets are advertised dynamically over BGP without modifying SmartConsole Encryption Domains or pushing security policies.

---

4. Virtual Tunnel Interface (VTI) Types & Gaia Configuration

Check Point Gaia OS supports two types of Virtual Tunnel Interfaces:

Numbered VTIs

• Definition: A point-to-point virtual interface assigned an explicit local IP address and remote IP address residing on a dedicated /30 or /31 subnet.
• Requirement: Essential when establishing BGP or OSPF peering sessions with third-party routers (Cisco, AWS VGW) that require explicit peer IP endpoints.
• Gaia Clish Setup:

# Configure a Numbered VTI peering with remote gateway 198.51.100.25
set interface vti vti1 remote 198.51.100.25 local 10.255.1.1 remote-address 10.255.1.2 prop-method ipsec
set interface vti vti1 state on

Unnumbered VTIs

• Definition: A virtual interface that borrows its IP address from an existing physical interface (e.g., eth0). Does not consume additional IP subnets.
• Requirement: Ideal for large Check Point-to-Check Point hub-and-spoke networks running static routing or OSPF where IP address preservation is critical.
• Gaia Clish Setup:

# Configure an Unnumbered VTI borrowing local IP from eth0
set interface vti vti2 remote 203.0.113.50 local-p-interface eth0 prop-method ipsec
set interface vti vti2 state on

BGP Dynamic Routing over VTI Example

Once the VTI (vti1) is operational, standard Gaia Clish dynamic routing commands establish dynamic peering:

set bgp autonomous-system 65001
set bgp peer 10.255.1.2 remote-as 65002
set bgp peer 10.255.1.2 state on