Should you stack two VPN layers? Three conditions to check

Before you add a second encryption layer to a VPN, answer one question honestly: what does the observer still hold after both layers have done their work? If the answer is the inner ciphertext, unchanged, then nesting bought time and nothing else. What follows is a decision procedure rather than a recommendation. The same diagram is wasted CPU in one deployment and the right answer in another, and only three conditions separate the two.

Write down what the observer keeps

Record the object an adversary can store today, then the sequence of removals that would eventually expose plaintext. An outer tunnel produces ciphertext; when its protection ends, what remains is the inner tunnel's ciphertext, still sealed. Removing a wrapper is not decryption. That sentence describes nesting, and it holds only while the inner key survives. The moment the two layers share anything, the timeline collapses into a single event.

So the useful artefact is a timeline, not a diagram of boxes. For each layer, write the endpoint, the key owner, the identity check, and the year the assumption is expected to fail.

A practical way to test your own claim: assume the observer records everything and never gives up. Under that assumption, does the design still protect the payload for its required lifetime? If the answer depends on the observer choosing not to store traffic, the design has no answer.

Condition one: do the layers stop at different places?

Nesting pays when the two layers terminate in different trust domains, for example a provider-managed IPsec gateway in front of an application-level tunnel that ends inside your own network. Breaking the outer layer then yields ciphertext that only your host can open, and the provider never sees plaintext at any point. Put both layers on the same gateway and that property disappears. Whoever compromises the box reads the traffic between the two decrypt operations, however many wrappers the diagram shows.

Check that with the installed state rather than the design. On Linux, ip xfrm state lists every security association and its endpoints, which settles where each layer actually stops.

Condition two: is the key material actually independent?

Two layers built from one certificate, one pre-shared key or one vendor library are one layer with extra steps. A single credential compromise then unlocks both, and a single implementation bug removes both at once. Independence has to be visible in the configuration, not asserted on a slide.

This is where hybrid key establishment beats stacking tunnels. IKEv2 can carry several key exchanges in one negotiation, so a classical group and a post-quantum KEM can both feed the same session keys instead of being wrapped around each other. The result is one security association whose keys depend on both secrets, and an attacker has to break both. That is a documented construction with a defined composition, which a homemade stack of two VPN products is not. On strongSwan, swanctl --list-sas prints the negotiated proposal for each SA, which is how you confirm what ran rather than what you configured.

Condition three: does the data outlive the outer assumption?

A layer that has to hold for twenty years needs a twenty-year argument. Recording now and decrypting later is cheap, and it is the reason a classical outer layer cannot be treated as a temporary wrapper around something stronger.

Ask when each key becomes recoverable, not whether the cipher is broken today. A static key exchange without forward secrecy fails retroactively on the day the private key falls. Ephemeral key agreement fails only for sessions an adversary can attack while they are live, or when the algorithm itself weakens. That difference decides whether an inner layer still helps in 2040. It also decides whether the outer layer changes anything at all, because an outer layer with the weaker key lifetime simply becomes the earliest point on the timeline.

What to build instead when the answer is no

If any of the three conditions fails, drop the nesting and spend the effort on the layer that actually carries the lifetime requirement. Configure a hybrid key exchange in the protocol you already run, keep the implementation current, and write down the composition you rely on. Naming ML-KEM in a design document is not a security property, and FIPS 203 defines the key-encapsulation mechanism, not your tunnel.

Where a second layer genuinely earns its place, describe it as defence in depth rather than as a proof. Then verify the composition: which endpoint holds which key, which identity each side checks, and what an operator with console access can read. A design that survives those three questions is worth the extra CPU. One that does not is a diagram.

Before the change window, capture the current SA table and the negotiated proposals. After it, capture them again and compare, because the only evidence that matters is what the devices actually agreed to.