On 06/11/2018 04:55 AM, Mick wrote:
You'll need a trusted gateway to do the unwrapping and then forwarding
to the next hop (SSH forwarding). If you attempt TCP-tunneling
(TCP-over-TCP) you'll soon experience 'TCP meltdown' with upper and
lower TCP layers' retransmission timeouts.
I disagree.
If I can establish an HTTPS (or other TCP connection to carry TLS
traffic) out through multiple layers of NAT (SOHO router + CGN + ???) to
a server with a globally routed IP address, I should be golden.
NAT will do what it needs to with the internal IPs to establish the
connection from the deeply buried client out to the TLS VPN server.
The connection will (extremely likely) be kept alive with various
different methods (TCP keep alive or VPN keep alive or pings through the
VPN) such that the upstream gateway can send data back to the client
through the established VPN.
Arguably this is no different than a long lived HTTP(S) connection from
the same client deep behind multiple NATs.
There is no need for something in the middle to unwrap things.
It almost sounds like you're talking about trying to do something from
one computer behind one or more NATs to another computer behind one or
more NATs on the far end. — That is a far more complex and
significantly different problem.
Most corporate VPN users are road warriors and connect from random IPs
to a static globally routed IP that is open to the world.
How will you be able to account for such a multi-NAT routing arrangement
if (in tunnel rather than transport mode) the original entire IP datagram
is encrypted and encapsulated? You'll need to decrypt it, take the
payload and read its IP header before you know where to forward it to.
Let me know if my comments above don't answer your question.
On single NAT you encapsulate the IPSec into UDP (NAT-Traversal), but
on a double NAT what will you do?
On the second NAT, you pass the UDP traffic from the first NAT.
I've never heard of double/triple NAT-T without port forwarding ...
There is no specific need for port forwarding in any of the NATs when
the traffic is originated outbound from the innermost client going out
to a static globally routed IP. — Just like there's no need for it
when making an HTTPS request from the same client system.
Do you mean VPN within UDP within VPN? You'll need intermediate VPN
gateways for this.
No. L2TP and / or PPTP are notoriously flaky with NATs. But it's
usually possible to get a single L2TP / PPTP VPN to function behind a
NAT. This is because the NAT sees the L2TP or PPTP traffic and
associates it with a single VPN client behind the NAT. If (when) there
is a second VPN client of the same type, it breaks the association of
which internal client the traffic goes to. Thus it usually breaks /
prevents all such clients from working at the same time.
--
Grant. . . .
unix || die
