Why a Working VPN Still Times Out on the Reply
A request reaching a private server is half the exchange. Its answer has to find the tunnel client through the intended gateway, route or translation.
The request arrives, the server logs it, and the client still reports a timeout. That combination means the reply did not find its way back, and it is one of the few failures you can confirm from two ends at once. Work the checks in order and stop when one of them fails.
Start with where the request arrived
Confirm that the packet reached the service before you inspect anything else. A server-side log entry, a connection counter or a permitted capture at the far end all answer the same question, and their absence sends you back to the tunnel rather than forward to the reply. This is the check that separates a forwarding problem from a return-path problem.
If the request never arrived, stop here. The tunnel, the routing to the private prefix or the access rule is the subject, and the reply path is not yet relevant. Also note the source address the server observed. It is either the pool address the client was given or a translated address, and that difference determines which of the later checks applies.
The reply needs a route to the pool
A remote-access client usually receives an address from a pool, and the private network needs a route back to that pool. A server whose default route points at its own gateway hands the packet to that gateway, which has no idea where the pool lives, so the reply dies there. The client sees a timeout because nothing came back, which is indistinguishable from a request that never left.
Check the route the server selects for the client address rather than the route it uses for its own subnet. Those two lookups can produce different answers, and the second one is the one that matters here. Translation is the alternative design and it changes what the server sees. It can simplify a return path, and it also removes the original client address from the server's logs, which affects any rule or report built on that field.
Compare the server capture with the gateway capture
Compare what leaves the server with what arrives at the gateway. A capture on the server's outbound interface and a capture on the tunnel gateway answer different halves of the question, and the gap between them localises the loss.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
A request generated by the gateway itself is a poor substitute for a client test, because it originates from a different address and meets different rules. That is why a successful ping from the gateway and a failing request from the client can both be true.
Where several routers sit on the path, check each one that needs a route to the pool. A site-to-site design often requires the remote prefix to be known at more than one device, and the gateway itself has to forward between the tunnel and the LAN; the strongSwan forwarding notes cover the sysctl and firewall side of that.
Record the pool, the prefix and the owner
Four facts belong in the note: the pool the client received, the private prefix it needed, the router responsible for the reply, and the translation rule if one exists. With those, a later gateway change is a comparison rather than an investigation.
Then retest with an ordinary client and the real application account. Broadening application privileges cannot repair a packet's return path, and an account change made during this diagnosis will confuse the next comparison. If the design relies on translation, document it where the server's logs are read. The person who sees an unfamiliar source address in an audit trail should not have to rediscover the mapping from a ticket.