VPN where local private address collide

[Terje Elde]

On 17. aug. 2013, at 12:42, Frank Leonhardt <freebsd-doc at fjl.co.uk> wrote:
> The setup is basically as described and the desired outcome is to NAT "the other end" so the addresses appear different.

That's a solution to a problem, but I don't yet know what the problem is, which makes it harder to give any advice. 

Do you need "everything" to work in both directions? If so, then what is "everything"?

Say both networks are at 192.168.0.0/24, and you remap so network A is available as 192.168.1.0/24 in network B, all machines at the same last octet (you can do that), and fix DNS for it. All good right?

Well, it's not always that simple. Say you have a server running at 192.168.0.5 in network A, available at 192.168.1.5 in network B. A client connects (successfully) to it, ask for some data, and the server says "Get the data at 192.168.0.5:45756". Now the client will try to connect to that ip/port in network B, rather than following DNS for the IP that goes over the VPN and through the NAT, and get nowhere. 

You first hearing of that can be someone saying "The Foo-server is broken". You've just layered hack on top of hack, so you don't initially know if it's the user, his computer, the server, the VPN, the NAT or DNS, an incompatible protocol that doesn't like the setup, or the weird routing you'll have to set up. 

If you're looking at this as an easy fix to reach a specific server or service, by all means. But if you're looking at this as a general solution to bridging two networks, then just don't do it. Save yourself the grief, because if this works at all, it's down to luck, and even if you're get lucky now, you might not stay lucky. What happens if you add VoIP to the mix in two years? Or teleconferencing in three?

Basing network-design on present and future luck is just going to give you more grief that I than I'd wish for anyone. 

Terje