From owner-freebsd-questions@FreeBSD.ORG Tue Aug 20 18:14:21 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 F11D37E7 for ; Tue, 20 Aug 2013 18:14:21 +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 65AF821E9 for ; Tue, 20 Aug 2013 18:14:21 +0000 (UTC) Received: from [10.130.11.119] (cm-84.210.76.250.getinternet.no [84.210.76.250]) (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 D02032E413; Tue, 20 Aug 2013 20:14:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: VPN where local private address collide From: Terje Elde In-Reply-To: Date: Tue, 20 Aug 2013 20:14:11 +0200 Message-Id: <01ED803C-F130-4A51-8AEE-FB60CF4CBD05@elde.net> References: <520E5EC0.5090105@fjl.co.uk> <9FB6809B-DD5D-4A04-8BD9-0271FAC03181@elde.net> <520F53A2.80707@fjl.co.uk> <520F8AA8.8030407@fjl.co.uk> <1FF39756-0555-4CD8-95B7-862F9644CF78@elde.net> <791847EC-8E72-4013-9157-7AD0ACB62A7D@elde.net> To: Adam Vande More X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: frank2@fjl.co.uk, FreeBSD Questions 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: Tue, 20 Aug 2013 18:14:22 -0000 On Aug 20, 2013, at 8:33 AM, Adam Vande More = wrote: > and while you can rewrite that on a NAT-box using an application level = gateway, you can not do that if the session is using SSL or TLS. >=20 > Complete BS. This seems to come down to a misunderstanding in the examples drawn up, = and of TCP/IP-headers (outside the SSL/TLS encryption) and SIP-headers = (inside the SSL/TLS encryption). Noone is arguing that SSL/TLS would give any troubles with changing TCP = or IP-headers during NAT, and that part seams clear both to the OP and = myself. It's the SIP-headers inside an encrypted SSL/TLS-session that a = NAT-layer wouldn't be able to change, even if it wanted to (and arguably = outside the scope of NAT). > I was referring to headers *inside* the SSL/TLS-layers. I thought = that was obvious, but I see I might not have been clear enough. >=20 > Not clear in the least. Expanding on what is so difficult about might = do a lot of us some good. Read up if you'd like: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg268807.html I'm not quite sure what part isn't clear, so please email me if there is = anything. Preferrably off-list, this tread seems to be stearing towards = you calling BS based on a misunderstanding, and that's probably not = adding a lot of value to -questions. > Yes, you can often still resolve it on the server, but just how messy = does one want to get stacking workaround on top of workaround, >=20 > Despite your protestations to the contrary, NAT and SIP work quite = weil together in basic configurations including TLS and the OP's = scenario. I can't explain your difficulties but perhaps when you = aren't at a mobile device you could answer a question in depth. >=20 >=20 > The server would register that the phone is available at 192.168.0.200 = (locally, in lan_b), while the server would actually need to send to = 192.168.2.200, in order to reach 192.168.0.200 in lan_a. > =20 >=20 > Exactly how this would behave depends on a lot of factors, but you'd = quickly end up with a situation in which the phone *appears* to work, = can register against the server and call out (both client-initiated), = but where incoming calls just don't work (sent to 192.168.0.200 in = lan_b, rather than in lan_a). >=20 > Could you could post your config to demonstrate what you are doing = incorrectly? I'm not doing anything incorrectly or otherwise, and I'm not having any = difficulties with anything. I drew up an example, to illustrate a = point. And I know very well that NAT and SIP with TLS *can* work quite well in = such a setup. In fact, I'm even arguing it. If the server does the = right thing in a non-standard scenario, things can work quite well out = of the box even. However, if the server doesn't do the right thing in = this scenario, you might have a good bunch of debugging on your hands. I've never argued that you can't get it to work, I'm arguing that the = farther away from standards you go, the more you might break and have to = fix or find workarounds for. Terje