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
signature.asc
Description: This is a digitally signed message part.
