Publish a LAN service on the VPN gateway's own address

Presenting a LAN device at one of the gateway's own tunnel addresses takes a single line of NAT. The connection still fails, because the device answering has no idea that the client's address is reachable through that gateway. Walk the packet from the client inward, then walk the reply back outward, and the missing half becomes obvious.

Start from the client's view

The client in this example sits in the VPN pool 10.62.0.0/24 and connects to 10.62.0.1 on port 8080. That address belongs to the gateway itself, so the packet arrives at the gateway's kernel rather than at another peer. Behind the gateway, the LAN is 172.21.4.0/24. The gateway holds 172.21.4.10 and the device that actually serves HTTP is 172.21.4.40.

An address that belongs to a different VPN peer is not interchangeable with the gateway's service address. If the client is connecting to a peer's address, no gateway rule is involved at all, and this whole walkthrough is the wrong one.

Scope the destination translation on purpose

The narrow version presents one port and rewrites only the destination. The packet keeps its protocol and its source, which is what makes the rest of the walk interesting.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

A rule without protocol and port criteria is the broad version: it preserves whichever port the client chose while changing only the address. That is legitimate when the whole host is meant to be presented, and wrong when one service was the intent. Read the rule back and confirm the interface name. A DNAT rule on the wrong interface matches nothing, which produces the same timeout as a missing rule and wastes an hour of looking at the device.

Let the forwarding boundary agree

Translation changes the header; it does not grant permission. With a default drop policy the forwarded flow needs its own accept, and the return direction needs the established rule your policy probably already has.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

An unconditional accept for every DNAT flow is broader than this design and will also permit mappings added later by someone else. Name the destination and the port, and let the rest fail closed. If the counters on the forward rule stay at zero while the NAT counters rise, the packet is being dropped before your rule. Read the chain order rather than adding a second copy.

The device has to answer somehow

After translation the device sees a source in 10.62.0.0/24. Its reply goes to its default gateway, which is the LAN router, not the VPN gateway, unless something tells it otherwise. Two arrangements fix that, and they are not equivalent. A route on the device or on the LAN router sends 10.62.0.0/24 to 172.21.4.10, preserving the client source. A scoped source translation hides the client behind the gateway's LAN address instead.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Choose by what the service needs. Per-client policy and meaningful logs want the routed form; a device that cannot be given a route, or a service that simply must see a LAN address, points at the translated form. Do not reach for a global masquerade rule to make one reply work. It hides every client from every destination and quietly breaks the policies that depend on source addresses.

Do not test from the gateway itself

A request generated on the gateway to 10.62.0.1 leaves through the OUTPUT chain, not through incoming PREROUTING. Its failure or success says nothing about the client-facing rule, and testing there is how people conclude a working rule is broken.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Run a real client request and read both. The conntrack entry shows the translation that was applied, and the captures show whether the request crossed to the LAN and whether a reply came back toward the tunnel. Use a fresh connection after changing rules, because existing state keeps its earlier mapping and will keep failing in the old way. Then confirm the whole conversation: the device address, the forwarding permission and the reply route all describing the same flow.