Planning Dual-Stack IKEv2 Private Access With strongSwan

A dual-stack tunnel is not one decision but three, and they can be answered differently. Which family the outer tunnel runs over, which families the client receives inside, and which families the protected services actually answer on. A design that treats them as a single choice either carries IPv6 it never needed or hands out addresses that nothing can route back. Separate the three and the rest of the configuration becomes almost mechanical.

Three Kinds of Address, Decided Separately

The outer address is how the two gateways reach each other, and it can be IPv4 while the inner traffic carries both families. The inner virtual address is the client's identity inside the tunnel, and each family needs its own pool. The protected prefixes are what the client may reach, and they belong to the services rather than to the tunnel. Confusing the third with the second causes most planning errors, because both look like private ranges.

IPv4-only outer transport with dual-stack inner traffic is a normal and well-supported arrangement.

Decide each one explicitly and write the decisions down. If the outer path is IPv4 only, say so and stop worrying about IPv6 endpoint reachability. If a family is assigned inside but nothing answers on it, either remove it from the plan or make those services genuinely dual-stack.

Allocate a Virtual Address in Each Family

In a swanctl configuration the client requests virtual addresses, and a wildcard in each family asks the responder to assign one of each. The responder draws them from pools, and pools are separate objects from the networks behind the gateway. Keep them separate in the plan too, because a pool overlapping a service prefix produces routing that looks correct right up to the moment traffic lands somewhere unintended.

Ask for both families when you need both, and ask for one when you do not, since an unused address is policy surface with no benefit. A specific request is a request rather than a reservation, and the responder can return a different value under its own policy. That detail matters wherever an address is hard-coded into a firewall rule or a monitoring check. Reference pools by name in the connection and keep service networks out of them.

vips = 0.0.0.0, ::

Generate your own unique-local prefix for the IPv6 pool rather than adopting a short example value. The example shows the shape of the setting, not a default to inherit.

Describe Destinations Apart From Pools

Traffic selectors describe what each side expects to exchange, so the gateway's local selectors should name protected service prefixes and not client pools. The client's remote selectors mirror that intent. When the two lists describe different objects, the tunnel can come up and still carry nothing useful.

Those same prefixes need return routes and permitted forwarding inside the gateway's network, for every family you enable.

That is where a private IPv6 plan stops being sufficient. Unique-local addressing buys private reachability and does not create public IPv6 egress, so a design that assumes the unnumbered family will simply follow the IPv4 masquerading rules will disappoint its users. If public IPv6 access is part of the requirement, it needs a routed plan and an upstream that agrees with it. Otherwise state plainly that the IPv6 side is private-only, which is an honest boundary rather than a limitation to hide.

Make DNS and Return Paths Intentional

Name resolution does not follow the transport. A resolver can return A and AAAA records across an IPv4-only tunnel, and the client will then try a family you never planned for. Decide which service names should carry usable dual-stack answers and make both of those paths deliberate. A name that resolves to a family with no working path produces a stall rather than a clean error, and stalls are far harder to diagnose.

Document outer endpoint reachability separately, including whether any NAT traversal is in play and which family it uses.

Then write the plan in six lines: outer endpoint, IPv4 pool, IPv6 pool, IPv4 service prefix, IPv6 service prefix, and the router that owns replies for each. A plan in that shape answers the questions an operator actually asks at three in the morning. Anything shorter leaves dual stack as a second address bolted onto an IPv4-only policy, which is how it usually ends up half working.