Branch VPN on 4G: Keep Identity Stable When the IP Moves

Start at the branch itself, on the 4G router's WAN status page. If the address you see sits in the carrier's private range rather than a public one, no port forward on that box will ever let the hub dial in, and the tunnel has to be built outward from the branch. That single observation decides the design. The rest of the work is making sure the hub recognises the branch by something better than an address that changes every few hours.

Where the tunnel has to begin

Check the address against the shared address space carriers use for their own NAT, 100.64.0.0/10, and against the ordinary private ranges. Seeing one of those on a mobile uplink usually means carrier-grade NAT sits between the branch and the internet, and inbound connections are not available at any price the branch can pay. When the WAN address is public but changes, you have a different, easier problem.

Dynamic DNS helps only in the second case. It gives a changing public address a stable name to dial, and it cannot create a mapping the carrier never provided. It is still worth configuring for the public case, because it removes the one manual step in a renumbering. What it must not become is the answer for a branch the carrier never made reachable in the first place.

Separate the address you dial from the identity you match

The hub needs a stable thing to be found at, an approved fixed address or a maintained hostname. The branch needs a stable way to be recognised, and in IKEv2 that is the identity payload it presents during authentication, independent of the source address its packets happen to carry. A string such as @branch-a.vpn.example works as that identity even while the mobile address changes hourly.

That string is matched against policy, not resolved through DNS, so do not expect a lookup to happen at tunnel setup. The hub's configuration has to name the expected identity explicitly, and with certificate authentication the identity also has to line up with what the certificate actually asserts.

Accepting any identity because the source address looks plausible is the failure mode to avoid. On a responder that means accepting any peer, with an identity wildcard and a shared secret, which authenticates a string rather than a device.

Write the hub side as a named peer

In strongSwan terms the responder side is a connection with right=%any, which accepts a peer from any source address, plus [email protected], which pins what that peer must claim to be. Add rightsubnet=10.20.0.0/16 for the branch LANs, auto=add so the connection is loaded without being dialled, dpd_delay=30s for liveness, and mobike=yes so an address change can be absorbed rather than treated as a new peer.

Other vendors express the same objects under different names, usually a dynamic or branch-office peer type with an identity field and a protected subnet field. Fill both in; a generic dynamic checkbox is not a compatibility plan.

Keep the branch as the initiator

On the branch, the mirror image applies: left=%defaultroute so the local mobile address is used as it currently is, [email protected] to present the identity, right=hub.example.com for the stable hub name, and auto=start so the tunnel comes up without a human. When the mobile link reconnects, the branch re-initiates and the hub matches the same identity against the same policy object.

Allow IKE on UDP 500, NAT traversal on UDP 4500, and the encapsulated ESP that follows, on both sides. Then leave them allowed: a rule that only opens during business hours will look like an intermittent tunnel.

Test the address change, not just the first handshake

Bring the tunnel up, confirm it, then force the branch onto a new address by toggling mobile data or airplane mode for a minute. Watch the security association list on the hub and check that the peer address changed while the identity did not. A tunnel that only works until the first carrier reassignment has not been tested at all.

Then check the protected subnets separately. An established SA says the peers authenticated; it does not say the hub has a route to the branch LAN or that the branch accepts traffic from the hub's side. Read the routing table and the firewall policy separately, then send a ping from a host rather than from the gateway, since the gateway is the least representative device on any network.

A stable identity turns the branch into a policy object the hub can name. It does not make a carrier-NAT address reachable, and it does not grant the rest of the organisation access to the branch by itself.