Public IP return routing: where does your server’s reply go?

The packet capture shows a request at the server. The application generates a response. The external client still waits until its connection times out.

If a public request arrives but the connection fails, inspect the reply’s source address, selected route and any firewall or translation state on the path. The response must use the identity expected by the client and a route compatible with those constraints. Different forward and return paths are not inherently invalid; stateful filtering, address translation or source validation can make a particular path fail. A delivered public address adds a path without replacing every existing route.

Check source selection and return routes on the server

Take a hypothetical server with a Fibmesh-delivered public address, 203.0.113.24, and a LAN connection through the office router. The address is a documentation example. An outside client connects to a permitted service on that public address over the delivery tunnel.

The response must retain the connection’s appropriate public identity and use a compatible return path. If it instead leaves through the office ISP with a source that the ISP does not carry for the site, upstream filtering may reject it. A later network address translation (NAT) device might also rewrite it into an address the client was not talking to.

Checking the default route is useful, but insufficient. Policy routing, source selection and tunnel routes can influence the actual result. Inspect the route decision for the response’s source and destination, rather than only reading one default-route line.

WireGuard’s routing and network namespace documentation illustrates the separation between the outer tunnel transport and the routes for traffic carried inside it. A tunnel handshake proves peer communication; it does not prove the application’s response selected the intended route.

When asymmetric routing works and when it fails

Internet routing can be asymmetric: traffic in each direction may traverse different routers. That fact alone does not invalidate an IP connection.

The practical constraint is the equipment and policy on those paths. A stateful firewall may need to see both directions. A translator needs the relevant NAT state or a supported equivalent arrangement. Source validation may reject a packet whose address does not fit the path used. RFC 3704 discusses reverse-path filtering and the complications introduced by asymmetric and multihomed routing.

Do not turn “keep replies compatible with the delivery path” into a universal claim that all asymmetry is impossible. Instead, identify which devices translate, filter or validate this connection, and design the return route around those constraints.

Return gateway replies through translation and the tunnel

Now consider a LAN server at 192.168.20.15 that cannot run the tunnel itself. A gateway receives traffic for a public address and uses destination NAT to send the permitted connection to the server’s local service.

If the gateway preserves the remote client’s source, the server may send its response to the ordinary LAN default router. That router may know nothing about the gateway’s translation. Preserving the source therefore requires a suitable return-route design.

A different arrangement uses LAN-side source NAT so the request appears to come from the gateway’s LAN address. The server replies directly to that gateway. This helps bring the response back to the device holding the translation state, at the cost of hiding the original client source from the server.

There is still another decision: the gateway must return the translated response through the appropriate delivery path. NAT does not, by itself, select the tunnel. The nftables manual documents connection tracking and NAT behavior; the onward routing policy remains part of the deployment.

Separate replies from new outgoing connections

A response belongs to an incoming connection. A server opening a new connection to a software-update site is a separate flow. Their routing requirements can differ.

An inbound-only gateway arrangement can carry the public service’s requests and responses through Fibmesh while unrelated new internet connections keep using the existing ISP. Selected outbound or full-tunnel behavior changes the scope deliberately. Plugging a one-port connector into a LAN does not automatically make it the route for every machine.

For each policy, specify both address families and the source identity the destination should observe. A diagram showing an incoming arrow and an outgoing arrow is not enough to settle those details.

Trace a complete request and response

Use one authorized external client and one application transaction. Check the request at the delivery interface and target, then check the response at the target and gateway or endpoint tunnel. Compare source and destination addresses at each boundary.

Record whether the application sees the original client or a translated gateway address. Review source-based rules and logs accordingly. Keep captures limited to the diagnostic need and exclude secrets from support material.

Fibmesh Public IPs delivery requires a supported endpoint or gateway configuration. Agree the response policy during setup and test it after relevant route changes. Success means the client completes the intended exchange, not merely that the server saw the first packet.