L2TP/IPsec connects on one network and times out on another
Same laptop, same profile, different network. Compare the IPsec stage, the NAT depth and the helper behaviour before touching the credentials.
The same laptop, the same profile and the same password work in one building and fail in another. That comparison is the most useful evidence in the ticket, and it is usually the first thing discarded. Between two access networks the exchange passes through different address translation, different filters and different router helpers. Keeping the client fixed and changing only the network is how you find out which of those matters.
Fix the Client Before Comparing Networks
Change nothing on the device until you have a record of the working case: client version, profile contents, server name and the time of the successful connection. Then reproduce the failure on the second network during the same session, so the client state is as close to identical as it can be. A profile edited between the two attempts invalidates the whole comparison. The goal is one variable, and that variable is the network.
Confirm ordinary internet admission on the failing network first, including a guest portal if one is present. A portal that was never satisfied produces a timeout that looks exactly like a filtered tunnel, and that check takes a minute.
Four Stages, Four Different Failure Messages
An L2TP/IPsec connection passes through four stages, and RFC 3193 describes the arrangement that binds the first two. IKE negotiation is where a filtered path produces a silent timeout. IPsec authentication is where a certificate or pre-shared-key mismatch produces an explicit rejection instead. The L2TP tunnel setup is where an established security association can still lead nowhere, and the PPP login is where a wrong credential finally produces a visible failure. Read the log for the stage that stopped, not for the last line it printed.
journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10
The strongSwan log shows whether the IKE exchange reached a proposal and whether the peer answered at all, which separates reachability from policy. The xl2tpd log picks up where IPsec ends, so an established security association with nothing in that log points at the L2TP stage. The route query confirms the client is sending toward the server address you think it is, which catches a stale DNS answer inherited from the previous network. Together the three outputs name a stage instead of a symptom.
Compare NAT Depth and Helper Behaviour
NAT traversal moves protected traffic onto UDP encapsulation when translation is detected, so the port numbers carrying a working session may differ from the ones in a static diagram. Allowing one setup packet proves nothing about the rest of the exchange, and an external port scan cannot tell you how the peer treats valid authenticated traffic. A second layer of translation changes the picture again, because the mapping now exists twice and expires on two different schedules. Carrier-grade translation on a mobile connection is the usual reason a working office profile fails on a phone hotspot.
Router helpers vary as much as the networks do. Some firmware intercepts and rewrites the exchange, some merely stops dropping it, and some applies the setting only in a legacy mode. Read the firmware's own description of the checkbox, and where a compatibility mode exists, test it as one deliberate change rather than three at once.
Outbound Client, Inbound Server: Two Different Problems
An outgoing client and an incoming server need different upstream reachability, and a pass-through feature that helps the first does nothing for the second. A home router that lets the laptop reach a remote gateway does not thereby accept inbound connections to a server behind it. Confusing the two sends you looking for port forwarding that was never the problem. State which role the failing device plays before comparing anything.
After a supported change, repeat the same connection and record the stage it reached. Keep the working profile and the failing-network note together, and do not reset credentials or reinstall the client, because that discards the evidence the comparison was built on.