Why OpenVPN Clients Miss the Gateway's IPsec Selectors

Ping a host behind the remote IPsec tunnel from the gateway and it answers cleanly, so the tunnel looks healthy and the ticket moves on. A connected client then tries the same host and gets nothing back. That ping was never evidence for the client's flow, because it left with the gateway's own source address and matched a different IPsec selector. Understanding why the two cases diverge is most of the fix.

The gateway ping tests a flow your client never uses

Source address decides which policy applies. A packet generated on the gateway leaves with an address from its local LAN or its tunnel endpoint, and the policy that matches it was written for exactly that case. A client's packet arrives on the OpenVPN interface carrying an address from the client pool, which is a different selector entirely.

That is why the failure looks like a routing problem when it is really a policy-scope problem. Reachability from the gateway proves the peer is up and the proposals negotiated, and it proves nothing about whether the pool is protected.

Push the remote prefix the application actually needs

Take the illustrative pair of 10.8.0.0/24 for connected clients and 172.30.239.0/25 for the protected remote network. What a client needs is a route to that second prefix, not to the gateway's LAN and not to some other tunnel address. A route pushed to the pool is what makes the client hand that traffic to the gateway at all. Without it, the packet never reaches the policy decision you are debugging.

In a Community server that accepts pushed routes, the directive takes the real mask: push "route 172.30.239.0 255.255.255.128". Access Server configures the same destination through the installed version's private-network or access-rule settings, with routed or translated mode chosen deliberately. Editing generated firewall chains instead of the owning configuration is how a working setup becomes impossible to reproduce.

After connecting, read the client's routing table rather than the server's intent. A route that covers only the pool means the push never arrived, and a default route through the tunnel is broader than this requirement and will surprise you later. Check the mask as well as the prefix, because a /25 pushed as a /24 sends traffic for neighbouring addresses into a path that cannot carry it. Then confirm the client selected the tunnel interface for that destination.

Make the selectors include the client pool

For routed access that preserves client addresses, the IPsec policy has to protect traffic between the pool and the remote prefix. Selectors written for the gateway's own LAN admit the ping and drop the client's request, which is exactly the asymmetry that started this investigation.

Inspect the negotiated policy as well as the configured proposals, for example with ipsec statusall on strongSwan or the equivalent status command for your implementation. With policy-based IPsec the ordinary route can point at a physical interface while matching traffic is still encrypted, so a missing tunnel device proves nothing. Compare the selector pairs against the pool and prefix you wrote down.

Generic source NAT on the gateway can break the match as well. If a masquerade rule rewrites the client's source before the policy check, the packet no longer looks like the selector you wrote. That is one reason a broad masquerade rule is a poor second-VPN fix: it changes which policy applies and which address the remote side logs. Exempt the traffic you intend to route, or translate it deliberately and update the selectors to match.

Choose routing or translation on purpose

Routing keeps the client address visible to the remote side, so remote logs and per-source rules stay meaningful, and it requires the remote gateway to know the return path to the pool. Translation hides the pool behind one address, which removes the return-route problem and destroys the per-client identity.

Pick one design and write it down, because the two need different selectors and different firewall ordering. A half-applied masquerade lands between them and satisfies neither. The written choice is also what lets the next engineer tell a bug from a deliberate decision.

Close the loop on forwarding and the reply

The gateway has to forward the protocol and destination you intend, which means IP forwarding enabled and a forward chain that permits the pair. The remote side then has to send replies back through the IPsec path, and that is a routing decision on their gateway rather than on yours. Both halves are ordinary configuration, and both are easy to leave half finished. Test them separately so a missing forward rule is not mistaken for a broken tunnel.

Verify with one real client-to-application request, watching it cross the OpenVPN interface, the IPsec decision and the remote host. Inspect the reply as a separate observation, because a request that arrives and a response that never returns look identical from the client's seat. One traced request is worth more than any number of gateway pings.

Keep the destination authorization narrow while you test, and confirm that a client without the rule cannot reach the service. An installed route plus an established association is not the same thing as granted access.