Second L2TP Client Kills the First? Read the Encapsulation

One laptop holds a working tunnel through the office router. A second laptop in the same room connects, and the first one drops. If that is the whole symptom, three different causes are still on the table, and which fix applies depends on things you have not measured yet. The shared router is relevant, but it is not automatically guilty, and neither is the protocol.

Three causes that look identical from the sofa

The first candidate is the router's handling of IPsec. Cheap consumer routers often advertise pass-through and implement it for a single client at a time, because the mechanism tracks one peer and cannot separate two laptops behind the same public address. The symptom is exactly what you would expect: the newer session wins.

The second is the account. Many VPN servers permit one session per identity and disconnect the older one when the same credentials authenticate again, which is a policy decision on the gateway and has nothing to do with your router. Look for that explicit message in the server log before you buy hardware.

The third is a plain misconfiguration: two profiles pointing at the same identity, one of them with a stale pre-shared key or a certificate the gateway no longer accepts. That one usually shows up as a failed second connection rather than a dropped first one, so the shape of the failure is already telling you something.

What L2TP/IPsec actually sends through the router

IKE runs over UDP 500. The data path is ESP, which is IP protocol 50 and carries no TCP or UDP ports at all. A router that only understands ports therefore has nothing to key on, which is exactly why the pass-through machinery exists.

With NAT traversal, ESP is encapsulated inside UDP 4500. Now the router has a source port to map, and each laptop gets its own translation, so the gateway can tell two flows apart. That is the mechanism that makes multiple clients behind one address work at all.

The distinction matters when you read a router's feature list. A label that says IPsec pass-through tells you the vendor has some mechanism; it does not tell you whether that mechanism supports several clients or how it behaves when the second one arrives.

strongSwan's NAT traversal documentation describes the encapsulation itself, which is the part you can verify from packet captures rather than from a marketing page.

How to tell which cause you actually have

Run four observations and write down each result. Each laptop alone: does it work, and for how long? Both at once: which one survives? The second laptop on a phone hotspot: does the first stay up? And at the gateway: does the server log show a new session replacing an old one, or does it show one client simply going silent?

Those answers separate the candidates cleanly. A replacement message in the server log points at identity policy. A client that stops receiving traffic while the router shows a new translation points at the router. Two clients that both fail to complete IKE point at configuration or credentials.

Keep the same profiles throughout. Changing the profile between tests means you are measuring two variables at once, and the conclusion will be wrong in a way that is very hard to notice.

Capture on the router if it supports it, or on one laptop while the other connects. Seeing the second client's packets appear while the first client's stop is stronger evidence than any connected icon.

If the router is the constraint

Use the vendor's documented multi-client configuration if it exists, or replace the device with one whose documentation says what you need. That is an unglamorous answer and it is the only one that survives a firmware update.

What does not work is adding two identical inbound forwards toward two different laptops. A forward tells the router where to send arriving traffic; it does not tell it which of two active flows a packet belongs to, and the ambiguity is the bug.

If the router cannot be replaced, put one client behind a different path. A phone hotspot is a poor permanent solution and a perfectly good diagnostic one.

If the gateway is the constraint

Provision separate identities for separate people. One shared account used by two laptops is the arrangement that produces this symptom on servers configured for a single session, and no local configuration fixes a decision made at the far end.

Ask the gateway owner which policy applies: one session per account, one per certificate, or no limit at all. Their answer decides whether you need new credentials or a new router.

Verification is the part people skip. Run useful traffic from both clients for longer than the interval that used to fail, because two successful logins prove only that authentication worked once each.