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

[Mick]

On Monday, 18 June 2018 15:37:00 BST Grant Taylor wrote:
> On 06/18/2018 04:30 AM, Mick wrote:

> > The above does not offer him a route into the company's LAN and he cannot
> > connect to the servers *.i.company.com.
>
> Small nuance that routes don't deal with names and that names must be
> translated to IPs.  But that does require making sure there are routes
> to the proper name server to do said translation.

Yes, domain name resolution for remote hosts within the remote LAN space has 
to happen before routing to an IP address takes place.  If these remote 
machines are not publicly accessible, Hilco's PC will need to have configured 
his company's nameservers.

Some (all?) VPN clients use scripts to achieve this once a connection with the 
remote peer has taken place.  Many distros use dnsmasq to set up separate 
nameservers for split tunnels.  With Gentoo (without dnsmasq) I have found the 
remote peer's nameservers are written in resolv.conf by the VPN client Up 
script, but only for full tunnels.  I've noticed with strongswan when setting 
up split tunnels it errors out as it tries to set a nameserver for the tunnel 
side and ends up with the local default gateway nameserver only.  Of course 
remote peer private name space resolutions fail, because the local nameserver 
does not know anything about them.

Actually, I don't know if there is a way to set up multiple nameservers for 
corresponding name resolution in/out of the tunnel, without using a domain-
specific override as you would with dnsmasq and without leaking DNS queries to 
the ISP if you are meant to be querying the tunnel's nameservers.


> > When the above setting is left disabled, then Hilco can access the company
> > domain, but not the Internet - a full tunnel.  His route table now shows
> > tun0 as being the default NIC:
>
> It seems like you're using "full tunnel" to mean that everything is
> routed through the tunnel.  Save for the VPN tunnel traffic itself.
>
> I figured that's what you meant, but I wanted to ask and be sure.
>
> > My understanding of a "split tunnel" or "split horizon" as you call it
> > involves two routes:
> >
> > 1. Route for connections via the VPN tunnel:
> >
> > One route is used to direct datagrams from a local subnet or a virtual
> > VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1,
> > via the VPN tunnel (tun0) to the remote company's LAN.
> >
> > 2. Route for all other connections, outside the VPN tunnel:
> >
> > A second route is typically the default route of the PC for all other
> > connections and it is used to route datagrams outside the VPN tunnel.
>
> Agreed.  Though there may be more routes for additional subnets routed
> through the VPN.  This is what I think Hilco is wanting to do.
>
> > Some VPN clients add a new routing policy rule table (e.g. strongswan),
> > but others (e.g. racoon) add routes for the VPN tunnel in the main
> > routing policy rule table.
>
> I was not aware that any VPNs used alternate routing tables and rules to
> use them.  But that does make sense.  Programmatically, that may be
> simpler to maintain and clean up after the VPN is shut down too.  I.e.
> assume that anything in the routing table is for the VPN and safe to
> remove, along with the single predictable rule referencing said table.

Yes, those VPN implementations that set up separate routing policy tables help 
to keep main and 'VPN' rules separate, which is neat and easy to maintain.  
From memory Strongswan in particular sets up a rule table with ID 220, which 
only contains the route from the local VPN subnet to the remote LAN subnet.


> > In contrast, a "full tunnel" directs all outgoing datagrams from any
> > local subnet via the VPN.
>
> I agree at a high level.  The nuanced nitpicks don't matter at this point.
>
> > I appreciate what I describe above is inverse to what the setting "Use
> > only for resources on this connection" is meant to do, but I merely go
> > by the route tables Hilco has provided.
>
> My not-yet-awake brain doesn't see the inverse issue that you're
> referring to.  But I'm used to dealing with VPNs, so maybe something is
> instinctive for me.
>
> > Hmm ... prompted by your question in this post I had to give it a second
> > thought, and I've come up with this hypothesis:
> >
> > IF no specific subnet routes are defined on the NM routes tab AND the "Use
> > only for resources on this connection" is selected, then it may be that
> > networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes
> > will be tunneled via the VPN, leaving nothing for the default route.
>
> Using a (translated or not) route of "0.0.0.0/0" seems antithetical to
> "Use only for resources on this connection".

Quite.  The user (or his VPN client via some NM plugin) is meant to add in 
this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use 
only for resources on this connection" in order to set up a split tunnel.  
Then tun0 will only be used to tunnel connections to these subnets.  All other 
connections to the Internet or local LAN will go outside the tunnel, using the 
default local gateway.

Given Hilco's results I'm surmising an empty table in the NM translates as 
0.0.0.0/0 and all connections end up being routed via the VPN stack, but I 
could be wrong because I don't know what he may have entered in this table.

I recall a couple of years ago playing with AppleMac's NM settings to 
configure a split tunnel, but gave up on this route table palaver, because it 
was not behaving rationally at the time - or so I thought.  I couldn't achieve 
a split tunnel using it, so I used the cli to set up routes for the remote 
peer's subnet.


> > Without more information on NM's specific settings I'm not sure why
> > routing is screwed up like this.  :-)
>
> I don't think it is screwed up.  Enabling "Use only for resources on
> this connection" doesn't change the default route.  Disabling "Use only
> for resources on this connection" does change the default route.

Yes, but leaving the routes table empty ... it seems to tunnel everything 
through it ... I don't know without trying it out myself or getting more info 
on the settings.


> It does look like NetworkManager has the concept of additional routes
> that should be routed through the VPN.  However when hovering over the
> box that I think you enter them in, "Editing IPv4 routes for VPN
> connection $NAME", I get a tool tip balloon that says "IP addresses
> identify your computer on the network.  Click the Add button to add an
> IP address.".  Which makes one think the dialog box is for enter IP
> addresses.  However I suspect that's an artifact of how the dialog box
> is constructed and re-using the same code as for entering IPs.  The
> Address, Netmask, Gateway, and Metric fields do sound like routes.
> Though I question the wisdom of a static gateway in this case verses the
> tunnel device.

I expect you can set up a subnet here and from this the NM will configure the 
route accordingly to make it go through the VPN stack.


> > Nevertheless, adding a route manually for the remote LAN subnet as per
> > my previous post should deliver a 'split tunnel/horizon', assuming the
> > DNS nameservers are also somehow sorted out.
>
> I suspect that the client needs to be directed to use the DNS servers on
> the corporate LAN and ensure that their IPs / networks are also routed
> through the LAN.
>
> Or do something creative like run a local DNS server that knows to send
> queries for company.com to a DNS server through the VPN.

As I've mentioned above I've noticed strongswan fails to set up split tunnel 
DNS nameservers, or may be something is misconfigured on the remote peer's VPN 
gateway.  Is this something I can manipulate via resolv.conf on the local PC 
(without a local resolver) to make sure DNS searches meant for the VPN stack 
are tunneled to the remote nameservers not leaked outside it?

PS. Thanks for your write up on network namespaces.  I'll look into this in 
more depth when I get a minute, because I would like to contain/isolate 
desktop applications I inherently mistrust - e.g. Skype.

-- 
Regards,
Mick