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

[Mick]

Hi Grant,

On Monday, 18 June 2018 03:59:32 BST Grant Taylor wrote:
> On 06/17/2018 03:05 PM, Mick wrote:
> > TBH I wouldn't select "Use only for resources on this connection",
>
> I thought "Use only for resources on this connection" would enable (what
> I know as) "split horizon", which is what I thought the OP wanted to do.
>   In other words route company traffic through the VPN and route
> everything not to the company via the ISP.

I am not overly familiar with networkmanager and the OP has not shared any 
screenshots or tab-by-tab NM settings, but had a look on a Gnome desktop and 
when hovering over the "Use only for resources on this connection" setting in 
the IPv4 Routes tab, it offers this tip:

"If enabled, this connection will never be used as the default network 
connection."

This tip alone hints that enabling it ought to create a split tunnel, for any 
subnets defined within this tab to be routed via the VPN, but everything else 
to be routed via the default route.

When Hilco enabled it he obtained this route table:

 $ ip route
default via 192.168.151.1 dev eth0 proto static metric 100
$SOME_COMPANY_IP_1 dev tun0 proto kernel scope link src
$SOME_COMPANY_IP_1 metric 50
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric 
100
192.168.151.1 dev eth0 proto static scope link metric 100
$VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100

The above does not offer him a route into the company's LAN and he cannot 
connect to the servers *.i.company.com.

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:

$ ip route
default dev tun0 proto static scope link metric 50
default via 192.168.151.1 dev eth0 proto static metric 100
$SOME_COMPANY_IP_2 dev tun0 proto kernel scope link src
$SOME_COMPANY_IP_2 metric 50
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric 
100
192.168.151.1 dev eth0 proto static scope link metric 100
$VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100

> > because this creates a full tunnel.
>
> What does "full tunnel" mean to you?
>
> I would think that it's the same tunnel, just different traffic routed
> through it.

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.

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.


In contrast, a "full tunnel" directs all outgoing datagrams from any local 
subnet via the VPN.

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.

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.

Without more information on NM's specific settings I'm not sure why routing is 
screwed up like this.  :-)

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.

-- 
Regards,
Mick