From owner-freebsd-questions@FreeBSD.ORG Sat Aug 17 11:02:15 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A3B4266 for ; Sat, 17 Aug 2013 11:02:15 +0000 (UTC) (envelope-from terje@elde.net) Received: from keepquiet.net (keepquiet.net [78.46.162.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 03BD62220 for ; Sat, 17 Aug 2013 11:02:13 +0000 (UTC) Received: from [10.121.169.209] (2.150.34.152.tmi.telenormobil.no [2.150.34.152]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: terje@elde.net) by keepquiet.net (Postfix) with ESMTPSA id BFAE72E42C; Sat, 17 Aug 2013 13:02:10 +0200 (CEST) References: <520E5EC0.5090105@fjl.co.uk> <9FB6809B-DD5D-4A04-8BD9-0271FAC03181@elde.net> <520F53A2.80707@fjl.co.uk> In-Reply-To: <520F53A2.80707@fjl.co.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Terje Elde Subject: Re: VPN where local private address collide Date: Sat, 17 Aug 2013 13:02:02 +0200 To: Frank Leonhardt Cc: "freebsd-questions@freebsd.org" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:02:15 -0000 On 17. aug. 2013, at 12:42, Frank Leonhardt 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