Date: Sat, 17 Aug 2013 15:37:28 +0100 From: Frank Leonhardt <freebsd-doc@fjl.co.uk> To: Terje Elde <terje@elde.net> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: VPN where local private address collide Message-ID: <520F8AA8.8030407@fjl.co.uk> In-Reply-To: <B86F8EA5-67BE-4791-8CAE-6E70BB326500@elde.net> References: <520E5EC0.5090105@fjl.co.uk> <9FB6809B-DD5D-4A04-8BD9-0271FAC03181@elde.net> <520F53A2.80707@fjl.co.uk> <B86F8EA5-67BE-4791-8CAE-6E70BB326500@elde.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17/08/2013 12:02, Terje Elde wrote: > On 17. aug. 2013, at 12:42, Frank Leonhardt <freebsd-doc@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520F8AA8.8030407>