Route Between Private LANs Before You Add Another NAT

Two internal firewalls, one private transit segment, and a request to let a few hosts in each LAN talk to the other. The reflex is to stand up a VPN or add a second NAT layer, and both reflexes cost more than the problem deserves. Ordinary routing is enough when three conditions hold: the address ranges do not overlap, both sides can return traffic to the other LAN, and the transit segment is already trusted enough for the data. Check those three before you design anything, because each one changes the answer.

Three conditions that decide the design

The first condition is address space. If both LANs use the same RFC 1918 block, routing cannot distinguish them and translation becomes unavoidable rather than optional. The second is a return path: a route from A to B is useless unless B also knows how to reach A's LAN, and asymmetric knowledge is the most common reason a "routed" design silently drops replies.

The third is trust. Routing moves packets; it does not protect them. A private transit segment inside one building is a different proposition from a provider hand-off or a link that crosses a shared campus backbone. If the segment is not trusted, the answer is a tunnel between the two firewalls, and the routing plan below still applies inside it.

Only when all three point the same way does the simple design win. When one of them fails, fix that condition explicitly instead of papering over it with translation, because NAT hides the failure rather than resolving it.

Build the route plan on the transit network

Give each firewall an address on the shared segment and add one specific route per remote LAN. Nothing else about the existing configuration needs to move, and in particular the internet default route must stay exactly where it is. Replacing a default route with the peer firewall would send every unrelated destination across the transit, which is a much larger change than the one being asked for. The pfSense static routing documentation describes the same route-plus-gateway model for that platform, and the equivalent control exists on whatever firewall you actually run.

Firewall A serves 10.30.0.0/24 and firewall B serves 10.40.0.0/24, with the two transit addresses on 192.0.2.0/24. Each LAN host keeps its local firewall as its gateway, so the only new state is one route on each side. On a Linux-based firewall the same plan looks like this, and forwarding has to be enabled or the route will resolve while the packet is dropped.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Keep filtering separate from translation

Routing and policy are different controls, and the second one is where most routed designs actually fail. Permit the specific sources, destinations and services at the ingress boundary the packets really cross, and remember that an interface label such as WAN is a name rather than a statement about trust. A transit port carrying private traffic may still have private-address blocking enabled by default.

Then look at outbound translation before you conclude that no NAT is happening. Automatic outbound rules can rewrite traffic that was never meant to be translated, which destroys the source addresses the far side needs for its own policy and logs. Confirm the selected flows keep their original addresses, and leave the internet translation rules alone for the traffic that still needs them.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

When NAT is the honest answer

Translation earns its place when the address ranges genuinely overlap and renumbering is not available, or when a policy requires one side to see a single address rather than a subnet. In those cases a deliberate one-to-one or port-restricted mapping is a design decision with known consequences, not a workaround.

The consequence to state out loud is that the far side can no longer see or filter individual sources. Logs collapse to the translating address, per-host policy stops working, and troubleshooting becomes a hunt for which internal host owned a flow at a given moment. If none of that matters for the traffic in question, NAT is fine.

When the transit itself is the wrong assumption

If the shared segment crosses a provider, a shared switch fabric, or any path where another party could read the traffic, routing alone is not a complete answer. A tunnel between the two firewalls gives you confidentiality and peer authentication, and the route table inside it is the same table you would have written on the transit.

Decide that from the trust question in the first section, not from a habit about VPNs being more secure. A tunnel over a segment that is already private adds operational cost and another failure mode for no gain, while routing over an untrusted segment trades confidentiality for simplicity you cannot afford. Write down which of the three conditions drove the choice, and the next engineer will not have to re-litigate it.