IPSec Hub Connectivity

1\ overview 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 spokes — every nile site participating in the feature hubs — the customer controlled primary and standby ipsec termination points high level ipsec hub topology both tunnels are kept up; adaptive path selection owns the fail over decision 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 the first isp link configured during site bringup is used to form the ipsec tunnels to both the primary and standby hubs the active nile edge engine establishes tunnels to both hubs and keeps them up; routing sends remote subnet traffic to the primary hub by default if the primary hub fails, dead peer detection (dpd) triggers a route switch to the standby tunnel if the active edge engine fails, the second edge engine takes over and repeats the process 2\ prerequisites complete the following before configuring ipsec tunnels nile edge service subscription ipsec hub connectivity is delivered as part of the nile edge service; the site must be subscribed supported nile service block version nile support confirms that the nile service block at the site is running the software version required to support this feature site configuration completed first finish the site's settings — dhcp, authentication, segments, and wireless — before configuring ipsec why order matters the ipsec configuration depends on the completed site settings the source segments offered during tunnel creation are derived from the segments defined for the sites in the selected scope if the site settings are not complete, the expected segments will not appear in the tunnel configuration 3\ architecture & failover behavior 3 1 tunnel establishment 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) 3 2 steady state routing 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 3 3 primary hub failure 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 3 4 edge engine failure 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 4\ hub model & regional (multi hub) scoping 4 1 hub model each branch designates one or two hubs primary hub — the active tunnel under normal operation backup hub — a geo diverse second termination point; the standby tunnel 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 hub ip / fqdn (primary and backup) pre shared key or certificate reference (per hub) encryption domain — the prefixes that should be tunnelled (the remote subnets) 4 2 regional / multi hub scoping 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 5\ portal configuration step 1 — general configuration & site scope enter a name for the tunnel set priority — choose primary or secondary from the dropdown choose the sites that participate in the tunnel select all sites , or select scope and pick the specific sites once a site is selected, the portal displays the public ip address(es) of the first link added during that site's bringup use these as the tunnel endpoints to configure on the hub side 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 ) step 2 — peer configuration & policy peers — enter the hub's public ip / hostname / remote id and the shared secret these peer values are unique per tunnel — a different peer ip and shared secret for the primary and standby tunnels source segments — the segments belonging to the selected sites these are populated from the site configuration (hence the site settings prerequisite) remote subnets — the subnets that reside on the hub end (inside the data center or cloud) enter in ipv4 cidr notation (e g , 10 0 0 0/8); separate multiple values with commas ipsec policy — choose a preset (see section 6) 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 ) repeat for the standby tunnel create a second tunnel with priority = secondary using the backup hub's peer details (its own public ip/hostname and shared secret) 6\ cryptographic suite (policy presets) 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 nile strong gcm — strongest gcm based suite (aes 256 gcm, ecdh19) nile perf gcm 128 — performance optimized gcm suite (aes 128 gcm, ecdh19) nile cloud compat — broad cloud compatibility (aes 256 / sha 256, dh14 / modp2048) if you require specific phase 1 / phase 2 settings beyond these presets, please reach out to nile support phase parameter nile strong gcm nile perf gcm 128 nile cloud compat phase 1 ike version ike v2 ike v2 ike v2 phase 1 encryption aes256gcm16 aes128gcm16 aes256 phase 1 prf sha256 sha256 sha256 phase 1 dh group ecdh19 ecdh19 dh14 phase 1 lifetime (s) 28800 28800 28800 phase 1 dpd (s) 15 15 15 phase 1 nat t true true true phase 2 esp encryption aes256gcm16 ecp256 aes128gcm16 ecp256 aes256 sha256 modp2048 phase 2 pfs ecdh19 ecdh19 dh14 phase 2 lifetime (s) 3600 3600 3600 phase 2 replay protection true true true nile strong gcm nile perf gcm nile cloud compat