VPN where local private address collide

[Terje Elde]

On Aug 20, 2013, at 8:33 AM, Adam Vande More <amvandemore at 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.
> 
> 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.
> 
> 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,
> 
> 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?

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