Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Aug 2013 13:02:02 +0200
From:      Terje Elde <terje@elde.net>
To:        Frank Leonhardt <freebsd-doc@fjl.co.uk>
Cc:        "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>
Subject:   Re: VPN where local private address collide
Message-ID:  <B86F8EA5-67BE-4791-8CAE-6E70BB326500@elde.net>
In-Reply-To: <520F53A2.80707@fjl.co.uk>
References:  <520E5EC0.5090105@fjl.co.uk> <9FB6809B-DD5D-4A04-8BD9-0271FAC03181@elde.net> <520F53A2.80707@fjl.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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, wh=
ich makes it harder to give any advice.=20

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

Say both networks are at 192.168.0.0/24, and you remap so network A is avail=
able as 192.168.1.0/24 in network B, all machines at the same last octet (yo=
u 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 n=
etwork B, rather than following DNS for the IP that goes over the VPN and th=
rough the NAT, and get nowhere.=20

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

If you're looking at this as an easy fix to reach a specific server or servi=
ce, by all means. But if you're looking at this as a general solution to bri=
dging two networks, then just don't do it. Save yourself the grief, because i=
f this works at all, it's down to luck, and even if you're get lucky now, yo=
u 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 m=
ore grief that I than I'd wish for anyone.=20

Terje




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B86F8EA5-67BE-4791-8CAE-6E70BB326500>