Date: Tue, 20 Aug 2013 20:14:11 +0200 From: Terje Elde <terje@elde.net> To: Adam Vande More <amvandemore@gmail.com> Cc: frank2@fjl.co.uk, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: VPN where local private address collide Message-ID: <01ED803C-F130-4A51-8AEE-FB60CF4CBD05@elde.net> In-Reply-To: <CA%2BtpaK16UpCTagewUojKz_UTwSSgXhsqrWuv7nsp-Wxv%2B06W%2BA@mail.gmail.com> 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> <CA%2BtpaK16UpCTagewUojKz_UTwSSgXhsqrWuv7nsp-Wxv%2B06W%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 20, 2013, at 8:33 AM, Adam Vande More <amvandemore@gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01ED803C-F130-4A51-8AEE-FB60CF4CBD05>