| 1 |
On 06/11/2018 04:55 AM, Mick wrote: |
| 2 |
> You'll need a trusted gateway to do the unwrapping and then forwarding |
| 3 |
> to the next hop (SSH forwarding). If you attempt TCP-tunneling |
| 4 |
> (TCP-over-TCP) you'll soon experience 'TCP meltdown' with upper and |
| 5 |
> lower TCP layers' retransmission timeouts. |
| 6 |
|
| 7 |
I disagree. |
| 8 |
|
| 9 |
If I can establish an HTTPS (or other TCP connection to carry TLS |
| 10 |
traffic) out through multiple layers of NAT (SOHO router + CGN + ???) to |
| 11 |
a server with a globally routed IP address, I should be golden. |
| 12 |
|
| 13 |
NAT will do what it needs to with the internal IPs to establish the |
| 14 |
connection from the deeply buried client out to the TLS VPN server. |
| 15 |
|
| 16 |
The connection will (extremely likely) be kept alive with various |
| 17 |
different methods (TCP keep alive or VPN keep alive or pings through the |
| 18 |
VPN) such that the upstream gateway can send data back to the client |
| 19 |
through the established VPN. |
| 20 |
|
| 21 |
Arguably this is no different than a long lived HTTP(S) connection from |
| 22 |
the same client deep behind multiple NATs. |
| 23 |
|
| 24 |
There is no need for something in the middle to unwrap things. |
| 25 |
|
| 26 |
It almost sounds like you're talking about trying to do something from |
| 27 |
one computer behind one or more NATs to another computer behind one or |
| 28 |
more NATs on the far end. — That is a far more complex and |
| 29 |
significantly different problem. |
| 30 |
|
| 31 |
Most corporate VPN users are road warriors and connect from random IPs |
| 32 |
to a static globally routed IP that is open to the world. |
| 33 |
|
| 34 |
> How will you be able to account for such a multi-NAT routing arrangement |
| 35 |
> if (in tunnel rather than transport mode) the original entire IP datagram |
| 36 |
> is encrypted and encapsulated? You'll need to decrypt it, take the |
| 37 |
> payload and read its IP header before you know where to forward it to. |
| 38 |
|
| 39 |
Let me know if my comments above don't answer your question. |
| 40 |
|
| 41 |
> On single NAT you encapsulate the IPSec into UDP (NAT-Traversal), but |
| 42 |
> on a double NAT what will you do? |
| 43 |
|
| 44 |
On the second NAT, you pass the UDP traffic from the first NAT. |
| 45 |
|
| 46 |
> I've never heard of double/triple NAT-T without port forwarding ... |
| 47 |
|
| 48 |
There is no specific need for port forwarding in any of the NATs when |
| 49 |
the traffic is originated outbound from the innermost client going out |
| 50 |
to a static globally routed IP. — Just like there's no need for it |
| 51 |
when making an HTTPS request from the same client system. |
| 52 |
|
| 53 |
> Do you mean VPN within UDP within VPN? You'll need intermediate VPN |
| 54 |
> gateways for this. |
| 55 |
|
| 56 |
No. L2TP and / or PPTP are notoriously flaky with NATs. But it's |
| 57 |
usually possible to get a single L2TP / PPTP VPN to function behind a |
| 58 |
NAT. This is because the NAT sees the L2TP or PPTP traffic and |
| 59 |
associates it with a single VPN client behind the NAT. If (when) there |
| 60 |
is a second VPN client of the same type, it breaks the association of |
| 61 |
which internal client the traffic goes to. Thus it usually breaks / |
| 62 |
prevents all such clients from working at the same time. |
| 63 |
|
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
Grant. . . . |
| 68 |
unix || die |
Archives