VPN where local private address collide

[Frank Leonhardt]

On 17/08/2013 12:02, Terje Elde wrote:
> 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.

This is just the sort of problem Google will have when it buys Facebook :-)

Your explanation of the foul-up possible with NAPT is well made, 
although not really talking about the kind of NAT used on Home/SME 
routers (one public address hiding many private one) - I'm thinking of 
Basic NAT - one-to-one replacement, not one-to-many. (i.e. static 
address assignment). All the router (or firewall) needs to do is swap 
the IP address in the header as it passes through, and swap it back when 
it returns. The two hosts shouldn't notice a thing.

FWIW it works pretty well without NAT if you can avoid address 
conflicts, and in a small installation its possible. But consider this 
really trivial example:

Both LANS are on the same subnet. You connect a single local host to the 
remote LAN on a VPN. It should be allocated a remote address that 
doesn't conflict with anything there. So far, so good. Now you try to 
connect to a remote IP address. How does your host know which interface 
to use - local LAN or VPN?!? If you're doing Layer 2 on the VPN, ARP 
seems to sort it out but its hardly clean, and when you end up with a 
clash (same IP on local and remote) it's never going to work.

The obvious answer is IPv6, of course. I'm surprised no one has 
mentioned it yet.

For the NAT I'm talking about see RFC2663. Take a look a Section 2.8, 
last paragraph. This exact problem was described back in 1999 :-)

mpd does handle NAT (Section 4.14 of its manual). It doesn't go in to 
great detail execept to say it uses ng_nat, which in turn uses libalias 
(like natd). Looking at the ng_nat 'C' interface, NGM_NAT_REDIRECT_ADDR 
sounds like what I'm after but it all looks geared to NAPT (which is, I 
guess, what most people use NAT for). And I've got this nagging feeling 
that ipfw is going to be involved somewhere, just to make it really tricky.

Regards, Frank.