Public prefix through OpenVPN: fix the return path

Watch the tunnel come up and the client ping the far side, and then a public address that belongs behind the VPN answers from somewhere else, or not at all. That symptom usually has nothing to do with the cipher or the certificates. A provider-routed prefix is delivered as an IP route, and carrying it over OpenVPN means reproducing that route at two levels and preserving the source address on the return path. Bridging the WAN is not required, and adding the address to an interface does not create the upstream route.

The prefix has to be routed to you first

Ask the provider how the block is delivered. A prefix routed to your server's main address is a different animal from addresses the provider expects to reach directly on a WAN segment. Only the first model works with the design here.

If the provider routes 198.51.100.64/28 to your entry server, packets for that range arrive at the server and stop there unless you forward them. If the provider instead bridges the range onto your uplink, the server must answer ARP for it, which is a different problem.

Test the delivery model before touching OpenVPN: from outside, ping an address in the block and watch which interface receives it. If nothing arrives, no amount of tunnel configuration will help. If the address answers directly on the WAN, the provider is bridging rather than routing, and the design below does not apply.

Two routing levels: kernel route and iroute

OpenVPN needs the prefix in two places. The kernel must know that the prefix belongs to the tunnel device, so forwarded packets enter OpenVPN instead of the default route. OpenVPN must also know which authenticated client owns the prefix, which is the iroute entry in the client-specific directory.

The server-side route looks like this, with the prefix and mask matching the allocation:

ip route add 198.51.100.64/28 dev tun0

The client-specific configuration assigns ownership. Put it in the CCD file named for the client certificate common name, and confirm that directory is the one the server actually reads:

iroute 198.51.100.64 255.255.255.240

The OpenVPN routed-network documentation describes both levels and why they are separate. A kernel route without iroute sends packets into the tunnel with no owner, and OpenVPN drops them. An iroute without the kernel route leaves packets on the server's default path. Both mistakes look like a broken tunnel from the client side.

Where the service address lives

The delegated prefix is not the same thing as the tunnel's own addresses. Keep the link numbered from private space if you like, and place the public service address where the service actually runs.

On a Linux client that terminates the service locally, an individual host address is enough:

ip address add 198.51.100.70/32 dev lo

If the prefix is routed onward to a VM host or another LAN, configure that downstream path and its return route instead. Assigning every address in the block to the VPN client is not required and creates conflicts later.

Keep the public source on the way back

A reply from the delegated prefix must leave through the tunnel and reach the provider's route. If the remote host sends it via its own ISP, the source address looks spoofed and the provider or the destination drops it. The fix is a source-based rule or a dedicated routing table, not a wider NAT. Without it, the service works from the tunnel peer and fails from everywhere else.

At the entry server, a broad masquerade rule is the usual culprit. It rewrites the public source to the server's main address, and the client never sees the real one:

iptables -t nat -S POSTROUTING

Scope NAT to the private VPN clients that need it and leave the delegated prefix untranslated. Then confirm the server forwards the prefix at all, since a default-deny forward chain drops it silently.

Verify both directions before trusting it

Verification is four observations, not one. Confirm the provider route arrives, the kernel sends the prefix into the tunnel, OpenVPN attributes it to the right client, and the reply returns with the public source intact. Each observation has its own command, so a failure points at a layer instead of the whole design. Run them in that order after every configuration change.

Ask the kernel which path a delegated address takes, and watch the tunnel while a request runs:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Reverse-path filtering can undo a correct route. Check the effective setting on the tunnel and on the uplink, and remember that a strict mode rejects traffic whose source does not match the interface it arrived on:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Finally, test the failure case. Stop the tunnel and confirm the public prefix does not leak out of the ordinary uplink. Restoring the VPN should bring the service back without widening which ports the host exposes.