Same subnet on both ends: map the remote LAN to a free range

Home and the office both run 192.168.1.0/24, so a request to 192.168.1.1 has two possible answers and the client picks one without asking. Renumbering a working office network is rarely popular, and the router addresses are often baked into printers, cameras and documentation. A client-side address mapping can present the remote network under a free range instead, and the host part can stay identical so 192.168.1.20 appears as 10.203.41.20. The catch is that only some clients implement it, and it does nothing for the return path.

Two views of the same host

The mapping keeps the host portion and changes only the network part. The same machine then answers at two addresses depending on where you stand. Writing both columns down before you configure anything prevents a later misreading of logs and firewall rules.

Local devices at home keep their own 192.168.1.x addresses, which is the point of the exercise. The printer in the next room stays reachable while the office appears under a range that does not collide.

The argument order is the whole trick

The option takes a direction, a network and mask, and an alias: the first network is what the client sees, the alias is what the server sees. For resources that live behind the remote gateway, the direction is the destination form. Reversing the two networks because the last argument is called an alias is the mistake that produces a tunnel which connects and maps nothing.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

The route is what sends the client's packets for the new range into the tunnel; the translation rewrites the destination on the way through. A reply from 192.168.1.20 is rewritten back to 10.203.41.20 so the socket on the client stays consistent. A single host works the same way with a full-length mask, as long as the route and the mapping describe the same address.

This is an address mapping, not a port mapping. Two services on one host cannot be separated with it, and a protocol that embeds IP addresses inside its payload will still see the real ones.

The mapping does not create a return path

Translation happens at the client, so the server still has to route replies to the tunnel and its firewall still has to permit them. If the remote gateway does not know how to reach the tunnel subnet, the request arrives and the answer leaves by the wrong door; the mapping merely makes the failure look like a client problem.

Server-side rules should describe the addresses that exist on the server after translation, not the client-visible range. Copying the alias into an allow rule wastes an afternoon, because no packet on that side carries it.

Pick an alias range that does not collide with anything else the client routes: another VPN, a container network, a second office. A collision here reintroduces the original ambiguity under a different number and is harder to see because the addresses look unfamiliar.

Names and payloads survive the translation

A hostname that resolves to the real 192.168.1.20 sends the browser to the local device instead of the remote one, no matter what the routing table says. The private DNS answer has to point at the client-visible range, while the TLS certificate still carries the name the application expects. Test with the name rather than with the address, because the address can work while the name quietly resolves the wrong way. When the remote gateway also serves that zone, its own records need the client-visible range too.

Redirects, embedded URLs and applications that hand out their own address in a payload can break in ways no packet mapping can repair. Treat those as an application problem and size the effort accordingly before promising that renumbering is unnecessary.

Three checks before you commit

First, confirm the client implementation. Community OpenVPN supports this option; the OpenVPN 3 code base lists it among unsupported features, so a profile pushed to a Connect-style client may simply ignore it. A directive that is accepted and never applied is worse than an error, because the tunnel looks healthy.

Second, verify the route and the translation separately with a short diagnostic window at high verbosity, then test the actual service rather than a ping. Third, confirm that the local router and the remote resource remain distinguishable from the client, since that was the original goal.

If the client cannot do the translation, ask the gateway side for help or accept a renumbering. Adding more routes for the same address is not a design.