Combined or separate VPN gateway: pick by failure domain

Two appliances look more resilient than one until you notice they share the same power strip, the same hypervisor and the same upstream link. Counting boxes answers a question nobody asked; the useful question is what fails at the same time. Write the failure contract down first, then let it pick the topology. The runbook below produces that record.

What stops during one reboot

For a combined gateway, list what disappears during a reboot, a failed update or a hardware fault. If internet access and private connectivity both stop, that shared interruption is now part of your availability requirement, whether or not anyone wrote it down. The same exercise applies to a single appliance that terminates several roles: the list of services it takes down is the real specification.

For separate gateways, list what remains shared: power, the virtualization host, the upstream link, the identity provider, the management network. Two devices behind one failed switch are one failure domain with two hostnames. Separation that ignores those dependencies is a diagram, not a design.

Count the maintenance ownership as well. Another device brings configuration, monitoring, backups and a second recovery procedure, and none of that is free.

Mark where each rule is enforced

Trace one packet from the client to a private resource and back, and mark every place a policy is applied. A second router adds another point where route preference, translation or connection state can disagree with the first. Most mysterious failures in a two-gateway design live at that seam.

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

Write down where VPN protection ends and where the inner policy begins. If the path between the two appliances is permissive, the second box has not created a boundary; it has only moved the place where a boundary could have been. On a single platform, distinct policy zones can still be effective, and their effectiveness should be assessed from the rules rather than dismissed because the hardware is shared.

Stop if you cannot say which device enforces the rule that matters. That gap is the finding, not a detail to settle later.

Containment is a boundary, not a chassis

A separate device contains a compromise only when the path through it is restricted to what the other side needs. If both appliances accept any traffic from each other, an attacker who lands on one has the same reach as before. The containment claim belongs to the rule set, not to the inventory. Read the rules, say which flows are permitted, then decide whether the split bought anything.

The same logic applies to users. A VPN user who is trusted because of the network they arrived on is trusting location instead of identity, and NIST's zero-trust guidance describes the alternative: authenticate and authorize each request against the resource. That principle holds whichever chassis terminates the tunnel.

If the split exists to satisfy a compliance line rather than to change a flow, say so in the record. A control nobody can explain is the first one removed under pressure.

Recover what you can actually reach

Ask what recovery path survives when either role dies. When the only way to reach a broken VPN gateway runs through that gateway, a spare device elsewhere does not help the administrator who needs to fix it. An out-of-band path, a console and a documented rollback are the parts that make the design recoverable.

systemctl status strongswan
nft list ruleset
ip -brief address

Size the design for the complete supported workload rather than an isolated encryption number, because filtering and inspection consume the same hardware. Use vendor documentation and your own measurements instead of assuming that separation is faster or slower. Then write the decision record: which flows are permitted, which dependencies are shared, what a maintenance window takes down, what capacity evidence you have, and who owns each recovery step. That record is short enough to review and specific enough to revisit.

The runbook ends when the failure contract is written, the forwarding path has one named enforcement point per rule, containment is described by flows rather than by device count, and recovery works from outside the failed component. Choose the simpler arrangement that meets those requirements.