On Monday, 11 June 2018 17:47:16 BST Grant Taylor wrote: > 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.
As I understand it, the CGN router will rewrite the IP headers and ports from/ to the SOHO router using PCP. This is not a TCP-over-TCP tunnel. > 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. Outgoing connections will be OK, but to run a local server I believe you'll need to set up an external 'rendezvous server' to facilitate incoming connections, since the double NAT'ed local server will not have a public facing IP address. > 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. I'm trying to recall what I was thinking when I wrote this ... SSH reverse tunneling? Not sure. Outgoing VPN connections *should* work fine, incoming won't. > 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. I've tried that and couldn't get it to work - for reasons I explained below. > 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. Yes, in these cases you have to use different ports and set port forwarding per client. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
