IPSec Hub Connectivity

Some networks would require a private, encrypted path back to customer-controlled infrastructure — legacy applications, regulated data, or partner extranets. For these, the Nile Edge engine terminates IPSec tunnels from the Nile site to one or more customer-controlled hubs (for example, a Datacenter or a cloud VPC). Tunnel survivability is owned by the same Adaptive Path Selection (APS) loop that Nile already runs across public-internet paths.

Nile implements this capability as a hub-and-spoke model:

Figure 1: High-level IPSec hub topology. Both tunnels are kept up; Adaptive Path Selection owns the fail-over decision.

Key behaviors at a glance:

Complete the following before configuring IPSec tunnels:

During site bringup, the first ISP (WAN) link is designated for IPSec, and its public IP is used as the local tunnel endpoint. The active Nile Edge engine forms IPSec tunnels from this link to both the primary and standby hubs. Both tunnels are brought up and kept up at all times (IKE SA and CHILD SA established to each hub).

Although both tunnels are established, the system programs routes so that the gateway for the remote (hub-side) subnets points to the primary hub. The primary tunnel carries traffic by default; the standby tunnel stays up but idle.

The Nile Edge engine continuously monitors peer liveness via Dead Peer Detection (DPD). If the primary peer is declared dead and the standby tunnel is established, the engine repoints the gateway for the remote subnets to the standby tunnel, and traffic continues over the backup hub. Adaptive Path Selection owns the fail-over decision.

If the active Nile Edge engine itself fails, the second available Edge engine takes over and repeats the same sequence: it forms IPSec tunnels to both the primary and standby hubs, activates routing to the primary hub, and switches to the standby tunnel based on dead peer detection.

Each branch designates one or two hubs:

When two hubs are configured, both tunnels are kept up at all times. The active hub carries traffic by default; the backup hub carries traffic only when the active hub is unreachable.

Hub model parameters are configured per branch in the portal. For each hub the customer provides:

When creating tunnels you choose the sites under scope. This lets a customer with multiple regional hubs map sites to the nearest hub — for example, scope all West Coast sites to the West Coast regional hub, and all East Coast sites to the East Coast regional hub. You can therefore define multiple primary/standby hub pairs and attach them to different sets of sites defined on the Nile Portal.

Figure 2: General configuration — tunnel name, Priority (Primary/Secondary), and site scope selection. The Selected scope panel surfaces the site's first-link public IPs to use as hub-side endpoints. (Public IPs masked.)

Figure 3: Primary peer configuration — Peer Public IP & Shared Secret (unique per tunnel), Source Segments (from the selected sites), Remote Subnets (hub-side subnets), and the IPSec Policy preset. (Public IP masked; shared secret hidden.)

Rather than exposing a dropdown for every individual Phase 1 / Phase 2 parameter, Nile provides a set of curated IPSec policy presets. These cover almost all use cases and make it easy to configure tunnels consistently across the fleet: