Re: [gentoo-user] Enable "regular" network traffic when using VPN

[Mick]

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