Verdict

“The loopback‑anchor + SNAT design is unique but introduces more risk than benefit compared to mature multi‑link SD‑WAN platforms that already meet the always‑up tunnel requirement.”

The proposal introduces a novel loopback‑based anchor with SNAT to unify disparate WAN links and maintain always‑up IPsec tunnels, which is not a common pattern in standard SD‑WAN deployments. Existing solutions such as Fortinet SD‑WAN, Cisco Viptela, and VMware SD‑WAN already provide path selection, health‑checks, and HA for multiple links, but they assume the source IP is tied to a physical interface. Re‑architecting the tunnel source to a virtual loopback and translating that to a routable SNAT address adds significant complexity and potential single points of failure, especially in a noisy RF environment on a vessel. While this approach may reduce the number of per‑link tunnel configurations, it does not clearly solve the core problem of guaranteeing tunnel uptime when any link can become unavailable, and it introduces new operational challenges (SNAT stability, APIPA address handling, HA across the loopback). Competitors that already support multi‑link SD‑WAN with dynamic path selection and automatic failover would likely cover the same requirements with less custom code. Therefore, the differentiation is somewhat real but fragile and may not be durable under real‑world maritime conditions.

“Using a loopback adapter as a 'vpn-anchor' for IPsec VPN tunnels and steering traffic from it using SD-WAN rules is a viable approach for maintaining tunnel continuity across multiple WAN connections.”

The proposed solution involves complex network configuration with multiple WAN connections, SD-WAN, and IPsec VPN tunnels. The approach of using a loopback adapter as a 'vpn-anchor' and steering traffic from it using SD-WAN rules is feasible. However, the requirement to SNAT the loopback IP address to a routable IP address for each outgoing carrier connection adds complexity. The use of FortiGate 201F's with firmware 7.6.6 provides a robust platform for SD-WAN and IPsec VPN functionality. The main challenge lies in managing the multiple WAN connections and ensuring the IPsec VPN tunnels remain up across different links. The absence of routing protocols and the noisy RF environment may introduce additional difficulties. Nevertheless, the overall design is sound, and with careful configuration and testing, it can be implemented within a reasonable timeframe.

“Loopback-anchored tunnels with SD-WAN steering and per-egress SNAT is a robust pattern for unstable multi-WAN environments.”

Your approach is technically sound and addresses the core challenge of maintaining persistent IPsec tunnels across highly variable WAN links. Using a loopback interface as a stable anchor for VPN tunnels is a proven method in dynamic environments, and leveraging SD-WAN to steer traffic from this anchor is logical. The SNAT requirement is a minor hurdle - FortiGate supports policy-based SNAT, so you can translate the loopback's APIPA to a routable WAN IP per egress interface. The lack of routing protocols is mitigated by SD-WAN's health checks and failover logic. Potential gotchas: (1) Ensure SD-WAN rules prioritize links correctly (e.g., 5G > Starlink > Iridium) and account for latency/jitter in health probes. (2) Test tunnel re-establishment during link flaps - FortiGate's IPsec can be sticky; tweak `keepalive` and `rekey` timers. (3) Verify SNAT doesn't break VPN peer validation (some devices inspect source IPs). The VDOM simplification was wise - complexity here would compound operational risk. Your path is viable, but rigor in testing edge cases (e.g., simultaneous link failures) will determine success.

“Architectural complexity with single points of failure and unnecessary routing/SNAT complications doom this approach within 6 months.”

The approach is overly complex and ignores simpler, more scalable solutions. Relying on a single loopback adapter for all VPN tunnels introduces a critical single point of failure. SNAT complications and the need to manage routable IPs for a non-routable APIPA address add unnecessary layers of potential failure. Furthermore, excluding VPN tunnels from SD-WAN zones while including physical WAN links may lead to inconsistent traffic management and increased complexity in maintaining uptime for the 'must-stay-up' VPNs. Regulatory and platform risks are less immediate concerns compared to the inherent architectural flaws and high churn potential due to complexity-induced outages.

“Your loopback approach is creative but fights FortiGate's architecture; the viable commercial path is embracing SD-WAN tunnel proliferation with automation, then productizing that automation for the maritime MSP market.”

This is a legitimate, well-defined problem with a clear paying market: maritime/energy enterprises with complex multi-WAN vessels, plus the MSPs and systems integrators that serve them. The audience is narrow but high-value - offshore operators, icebreakers, research vessels, and superyachts - where connectivity downtime costs $10K-$100K+ daily. The unmet need is real: FortiGate's SD-WAN wasn't designed for this topology, and the vendor documentation is thin on loopback-based VPN anchoring with dynamic SNAT. Your approach is directionally correct but has a critical flaw. The loopback-as-IPsec-originating-interface pattern works on Palo and some Cisco platforms, but FortiGate's IPsec implementation binds to physical egress for IKE source selection. Your SNAT problem is a symptom: FortiGate won't let you easily SNAT loopback-sourced VPN traffic because the IPsec engine expects to see its own interface IPs in IKE negotiations. The 'right' FortiGate-native approach is SD-WAN member interfaces as tunnel endpoints with zone-based SD-WAN rules, but you correctly identified the config explosion (10 WANs × 2 tunnels = 20 tunnel configs minimum). A cleaner path: use SD-WAN zones for the VPN tunnels too - create a virtual-wan-link or performance-SLA group, accept the tunnel count, and automate with FortiManager scripts or Terraform. The loopback hack will break during HA failover or when FortiGate's kernel routing table recalculates egress. Gotcha: HA sync of loopback-based tunnels with dynamic SNAT is untested territory. Another: your APIPA source will confuse the dial-up peers' phase2 selectors unless explicitly allowed. The Iridium link needs explicit bandwidth/quality exclusion or your SD-WAN will try to build tunnels over 128kbps. Consider: FortiGate 7.6's SD-WAN overlay-as-a-service or switching one VPN to GRE-over-IPsec which handles dynamic outer better. Market size: hundreds of vessels globally need this, but each engagement is $50K-$500K in professional services. The real money is in repeatable automation, not one-off configs.