Dual-Transport WAN for Fourteen Rural Clinics

Start with why the current design fails. A floating static only reacts to interface state; it cannot see a brownout, a 900 ms latency spike, or a path that is up but losing 20% of packets, which is why takeover takes 40–90 seconds and why sessions die rather than degrade. BGP with a session per transport, BFD at roughly 300 ms × 3, local preference favouring MPLS, and the hubs advertising only a default route gives sub-second detection, a deterministic primary/backup order, and path visibility the systems team can read with a single show command. Clinics advertise their /24 and learn 0/0: no policy routing, no route-maps beyond a preference and a couple of prefix filters, which fits the stated skill set. SD-WAN adds per-application steering - EHR pinned to MPLS, Microsoft 365 broken out locally - plus FEC and packet duplication for lossy broadband, central templating, and per-link SLA dashboards. It does not remove the need to understand BGP or the tunnel topology, and it costs per-site licensing. Decision criteria: if EHR is the only critical application and there is no roadmap for direct internet breakout, BGP plus BFD plus IPsec wins on cost and on the team's ability to own it. If the 14 sites will need local SaaS breakout and broadband quality proves variable, SD-WAN pays for itself. Either way, note that fast detection does not prevent TCP resets when the tunnel endpoint changes; only application resilience or per-packet steering does.

Give the transit links a dedicated plan rather than carving from the clinic /24s: 10.255.250.0/24 split into /31s yields 128 point-to-point links, more than enough for 14 clinics × 2 transports × 2 hubs, and 10.255.251.0/24 holds one loopback per router. Use /31 rather than /30 because it doubles the usable link count and removes the subnet-broadcast ambiguity that causes typos on point-to-point links. Terminate the IPsec tunnels on loopbacks, not on physical interfaces, so a single carrier failure does not invalidate every tunnel sourced from that interface. For MTU: IPsec transport or tunnel mode over a 1500-byte path consumes roughly 50–73 bytes depending on mode, so set the tunnel interface MTU to 1400 and clamp TCP MSS to 1360 at both ends. Without the clamp, PMTUD blackholes appear as an EHR that hangs when it opens a large imaging study but works fine on small forms - the classic complaint that gets misdiagnosed as an application bug. If you use GRE over IPsec, overhead grows and you should clamp lower. Verify with a large-payload ping with the DF bit set from a clinic host to Dallas before go-live, not after.

The clinic's outbound choice and the hubs' return choice must agree, or the flow hits a stateful device from the wrong side and is dropped. Set a consistent, total preference order on both hubs: MPLS via Dallas best (local preference 200), MPLS via Denver 150, internet via Dallas 100, internet via Denver 50. Because both hubs run the same policy, the return path for any clinic prefix follows the same order the clinic used outbound, so asymmetry only appears during the reconvergence window, not in steady state. Do not use BGP multipath here - equal-cost paths across two hubs is exactly how you get deterministic asymmetry. Keep session state on the tunnels rather than on a single central firewall, or if a firewall is in the path, ensure both hub firewalls see the same flows (symmetric routing plus state sync, or a single active hub). What clinicians should expect on failover: BFD detects the loss in under a second and routing converges quickly, but established TCP sessions still break because the tunnel source address changes, and the EHR client is intolerant of resets. Be honest about that in the design document - sell fast reconvergence and automatic reconnection, not session survival. If session survival is a hard requirement, that is the argument that justifies SD-WAN's per-packet steering.