From owner-freebsd-questions@FreeBSD.ORG Tue Aug 20 06:33:09 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D4D4E1EA for ; Tue, 20 Aug 2013 06:33:09 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC68E260B for ; Tue, 20 Aug 2013 06:33:09 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kx10so327997pab.13 for ; Mon, 19 Aug 2013 23:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GlJzuGKT4CyxLjlZajLVhgaHMmgCcc/XD2GcaG+vMsM=; b=uOctEti0nqdN33MYimfzldP+8ApbuXsHDOZDo6jnZzL4y2OsqJyTT4mqb0YCujHXbx azX1psrBq4/69xJtUNj6qZW0WQG8pz+31rDcFdkn1c905Mxe60DGu5A7tJ3FL1lCVWYb vGk/ZvP/xQPl7aXA69hPGCljo3MTY2MWEoBDiPzkhEfofpva/p9f1dpa8YVXpgfQwxwm k2NEMkQ0uOtdSklZ+u3PsvTIaG3GWa3iZYiWJB2OjnhxQhDHFJBfYCsIVJL3y3j5c0QC 0PGhtwqBg/afxKHGGi/F7U308B0Ny3mIvzSUtDJ081YHIkSjLzp3ovfpZzYnIDviyQrK UTfw== MIME-Version: 1.0 X-Received: by 10.66.25.205 with SMTP id e13mr849603pag.180.1376980389140; Mon, 19 Aug 2013 23:33:09 -0700 (PDT) Received: by 10.70.92.79 with HTTP; Mon, 19 Aug 2013 23:33:09 -0700 (PDT) In-Reply-To: <791847EC-8E72-4013-9157-7AD0ACB62A7D@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> Date: Tue, 20 Aug 2013 01:33:09 -0500 Message-ID: Subject: Re: VPN where local private address collide From: Adam Vande More To: Terje Elde , FreeBSD Questions , frank2@fjl.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 06:33:09 -0000 On Sun, Aug 18, 2013 at 7:17 AM, Terje Elde wrote: > On 18. aug. 2013, at 02.43, Adam Vande More wrote: > > > What about SSL/TLS for example? How would the router swap the header > in an encrypted session? > > > > Same as it would any sessions since only the payload is encrypted. What > Frank calls basic nat, most people call static nat(at least people who have > read enough Cisco docs) and it works just fine. Also you are confusing > headers. > > The point I was aiming for was that even if you were to swap the IPs in > the IP-header on the gateway, some protocols still reference the IPs inside > the TCP-payload, Yes like IPSec as I mentioned. > 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. > Complete BS. > > 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. > Not clear in the least. Expanding on what is so difficult about might do a lot of us some good. > > 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, > 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. 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. > 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). Could you could post your config to demonstrate what you are doing incorrectly? -- Adam Vande More