Date: Tue, 20 Aug 2013 01:33:09 -0500 From: Adam Vande More <amvandemore@gmail.com> To: Terje Elde <terje@elde.net>, FreeBSD Questions <freebsd-questions@freebsd.org>, frank2@fjl.co.uk Subject: Re: VPN where local private address collide Message-ID: <CA%2BtpaK16UpCTagewUojKz_UTwSSgXhsqrWuv7nsp-Wxv%2B06W%2BA@mail.gmail.com> 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> <B86F8EA5-67BE-4791-8CAE-6E70BB326500@elde.net> <520F8AA8.8030407@fjl.co.uk> <1FF39756-0555-4CD8-95B7-862F9644CF78@elde.net> <CA%2BtpaK1kG5BtKjO%2BFrSXwkgTJ_k5K7HxtL8vih7Mq%2Bb7r6KYWg@mail.gmail.com> <791847EC-8E72-4013-9157-7AD0ACB62A7D@elde.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 18, 2013 at 7:17 AM, Terje Elde <terje@elde.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BtpaK16UpCTagewUojKz_UTwSSgXhsqrWuv7nsp-Wxv%2B06W%2BA>