Reach a remote /24 over a tunnel: NETMAP, DNAT or route?

You can reach a subnet behind a tunnel endpoint three ways, and a minute of fact-gathering usually disqualifies two. The facts are whether the servers out there must tell users apart, whether anyone there will ever dial toward your range, and who may edit the far-end router. Answer those three and the design picks itself. The rest assumes you run the endpoint and may edit its firewall.

Three options, and what each one actually changes

Prefix mapping, per-host DNAT and a routed prefix all move packets between the same two ranges, but they change different things. Mapping invents an alias range and rewrites addresses arithmetically in flight. Per-host rules also rewrite, except each destination is named by hand. A routed prefix rewrites nothing: packets keep the real addresses and both ends agree on where those addresses live.

Start the elimination at the far side, where the constraints are hardest to change. If a server there writes client addresses into logs, checks them against an allowlist, or hands them to another system, translating the source destroys its only identifier. If the far side must also dial in, translation is out entirely, because nothing there knows the alias exists. Only when the far side merely answers requests do the cheaper options become safe.

Prefix pairs, and why the sizes must match

NETMAP is a nat-table target that works on a pair of prefixes of identical length. It has no per-address table inside: it strips the prefix, keeps the host bits and reattaches them to the new prefix, which is why a /24 maps onto a /24 and never onto a /25. Position decides direction: a destination match in PREROUTING rewrites where a packet is going, and a source match in POSTROUTING rewrites where it came from.

A host at 192.168.2.17 appears to your clients as 10.50.1.17, and the last octet is not decorative — it is the same number on both sides. Add a host at 192.168.2.40 tomorrow and its alias is 10.50.1.40, with no rule to edit.

Clients still need a route for the alias range pointing at your box, unless the alias falls inside a subnet they already reach. The gateway needs no route for the alias, because destination translation runs in PREROUTING, ahead of the route lookup. Forwarding must be on as well, or the kernel drops the packet after the rewrite. The three commands below are the whole setup on a Debian-style gateway with clients on br0, the alias on 10.50.1.0/24 and the tunnel on tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

The reply has to find its own way back

Rewriting the destination only decides where a packet gets delivered. The far-side server still has to answer an address it can reach, and there are two ways to arrange that. Translate the source so replies return to your box, or leave the source alone and give the far side a route for the client range.

Masquerading on the way out is the shorter path: one rule in POSTROUTING and the far side sees your tunnel address, so it needs no route of its own. The cost is that every user collapses into one address, and per-user logs stop meaning anything. Leaving the source intact keeps that information, but the far site must then send replies for the client range back through the tunnel. On an OpenVPN server that is a pushed push "route 10.50.9.0 255.255.255.0", plus a route 192.168.2.0 255.255.255.0 line.

The expensive failure is doing half of each. If you masquerade some traffic while the far side also carries a route back for other traffic, replies arrive on an interface where the connection-tracking entry was never seen. The client reports a timeout for a request the server logged as served. Both directions of a flow must cross the same netfilter instance: one gateway translating, not two firewalls in series.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Read the entry in both directions: the original tuple keeps your alias on the destination, while the reply tuple carries the real address. If the reply tuple is absent, the return path is the problem rather than the rule. If the PREROUTING counters never moved, the packet never reached that hook.

Collisions and the lookup that runs first

Two different ranges can collide, and both failures look like a broken tunnel rather than a bad rule. The alias you invent must be unused along the whole path, and the real far-side range must not already exist on your network. A duplicate produces intermittent wrong-host traffic, which is harder to diagnose than a refused connection. Ask the routing table before you add a rule.

On the gateway, ip route get 192.168.2.17 should name the tunnel device; a local bridge means the far range is shadowed and no nat rule will repair it. If your own network already uses 192.168.2.0/24, renumber the far site instead of stacking a mapping on the collision.

Testing it from a real client, then keeping it

Test from a machine that will actually use the alias, not from the gateway, because locally generated traffic never traverses PREROUTING the same way. Open a connection to one aliased host and watch the counters and the conntrack entry appear together, then close it and confirm the entry leaves. A stale entry points at a half-open connection, which usually means the reply never came back.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Two or three successful connections prove the arithmetic, but they say nothing about persistence or about the next engineer. Save the rules where the boot process reads them, which on Debian and Ubuntu means iptables-save > /etc/iptables/rules.v4 with netfilter-persistent enabled. A mapping that vanishes on reboot is worse than none, because the outage arrives with no recent change to blame.

Leave a note beside the rules: the alias range, the real range, the reason for the pair and which side may initiate. That note separates a design from a pile of rules nobody dares delete. It also settles the later question, when the remote site adds a host and an address nobody configured already answers. If the note says the far side needs a route back, the next person knows that removing the masquerade rule breaks connectivity. Documentation is cheap here; rediscovering a NAT dependency at three in the morning is not.