-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On Wed, 2021-02-03 at 12:25 +0100, Thomas Haller wrote:
> On Wed, 2021-02-03 at 12:08 +0100, Chris Coutinho via networkmanager-
> list wrote:
> > Hello NM folks,
> > 
> > I'm running into a problem converting an OpenVPN "full" tunnel
> > configuration to
> > a split tunnel configuration. I've received an .ovpn file from a
> > client which,
> > by default, routes all my traffic through their VPN. I want to
> > configure my VPN
> > connection such that only traffic to/from resources within their
> > network are
> > routed through the VPN, and all other traffic is routed through
> > whatever network
> > I'm currently on.
> > 
> > I'm running:
> > - openSUSE Tumbleweed with Gnome
> > - Network Manager 1.28.0
> > - NM OpenVPN Gnome plugin 1.8.12
> > 
> > I can modify the connection profile to route traffic to publicly
> > accessible IP
> > addresses through the VPN by manually setting the ipv4.dns and
> > ipv4.routes
> > options using nmcli. I'm able to modify the VPN connection profile as
> > follows,
> > which allows me to access publicly resolvable resources.
> > 
> > # nmcli connection modify <split> ignore-auto-dns=true
> > # nmcli connection modify <split> dns=<local dns>    <- Current LAN
> > DNS
> > # nmcli connection modify <split> +ipv4.routes <host-ip-A/32> <-
> > public
> > # nmcli connection modify <split> +ipv4.routes <host-ip-B/32> <-
> > private
> > 
> > By public/private here I mean I can access host-A with these options
> > because my
> > LAN DNS can resolve the IP address, meanwhie host-B is unresolvable
> > and I can't
> > figure out why.
> > 
> > Connected to the full tunnel shows the following nslookup output for
> > an
> > "internal" host:
> > 
> > $ nslookup <the host>
> > Server:         8.8.8.8
> > Address:        8.8.8.8#53
> > 
> > Non-authoritative answer:
> > Name:   <the host>
> > Address: 10.243.a.b
> > Name:   <the host>
> > Address: 10.243.c.d
> > Name:   <the host>
> > Address: 10.243.e.f
> > 
> > If I'm connected to the "full" tunnel, inspecting the connection
> > profile returns
> > the following. I think the "IP4.ROUTE[1]" line means that all traffic
> > is being
> > sent through their gateway.
> > 
> > 
> > $ nmcli connection show "Client VPN (Full)"
> > GENERAL.NAME:                           Client VPN (Full)
> > GENERAL.UUID:                           6a647d45-1740-4a49-81d1-
> > 6d49f5631a40
> > GENERAL.DEVICES:                        wlp0s20f3
> > GENERAL.IP-IFACE:                       wlp0s20f3
> > GENERAL.STATE:                          activated
> > GENERAL.DEFAULT:                        yes
> > GENERAL.DEFAULT6:                       no
> > GENERAL.SPEC-OBJECT:                   
> > /org/freedesktop/NetworkManager/ActiveConnection/2
> > GENERAL.VPN:                            yes
> > GENERAL.DBUS-PATH:                     
> > /org/freedesktop/NetworkManager/ActiveConnection/49
> > GENERAL.CON-PATH:                      
> > /org/freedesktop/NetworkManager/Settings/29
> > GENERAL.ZONE:                           --
> > GENERAL.MASTER-PATH:                   
> > /org/freedesktop/NetworkManager/Devices/3
> > IP4.ADDRESS[1]:                         a.b.c.d/23
> > IP4.GATEWAY:                            a.b.c.1
> > IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh =
> > a.b.c.1, mt = 50
> > IP4.ROUTE[2]:                           dst = a.b.c.d/23, nh =
> > 0.0.0.0, mt = 50
> > IP4.DNS[1]:                             a.b.c.d
> > IP4.DNS[2]:                             a.b.c.d
> > IP4.DOMAIN[1]:                          <company.com>
> > VPN.TYPE:                               openvpn
> > VPN.USERNAME:                           <my username>
> > VPN.GATEWAY:                            a.b.c.d:1194:udp,
> > a.b.c.d:443:tcp
> > VPN.BANNER:                             --
> > VPN.VPN-STATE:                          5 - VPN connected
> > VPN.CFG[1]:                             ca = /home/chris/.cert/nm-
> > openvpn/client-ca.pem
> > VPN.CFG[2]:                             cert = /home/chris/.cert/nm-
> > openvpn/client-cert.pem
> > VPN.CFG[3]:                             cert-pass-flags = 0
> > VPN.CFG[4]:                             cipher = AES-256-CBC
> > VPN.CFG[5]:                             comp-lzo = no-by-default
> > VPN.CFG[6]:                             connect-timeout = 4
> > VPN.CFG[7]:                             connection-type = password-
> > tls
> > VPN.CFG[8]:                             dev = tun
> > VPN.CFG[9]:                             dev-type = tun
> > VPN.CFG[10]:                            key = /home/chris/.cert/nm-
> > openvpn/client-key.pem
> > VPN.CFG[11]:                            ns-cert-type = server
> > VPN.CFG[12]:                            password-flags = 1
> > VPN.CFG[13]:                            remote = a.b.c.d:1194:udp,
> > a.b.c.d:443:tcp
> > VPN.CFG[14]:                            reneg-seconds = 604800
> > VPN.CFG[15]:                            ta = /home/chris/.cert/nm-
> > openvpn/client-tls-auth.pem
> > VPN.CFG[16]:                            ta-dir = 1
> > VPN.CFG[17]:                            username = <my-username>
> > 
> > 
> > Is there anything I can do to fix this configuration and route only
> > private/internal traffic through the VPN?
> 
> 
> Hi,
> 
> I think routing and DNS are mostly independent things.
> 
> 
> Setting up routing so that only a certain subnet is reached via the VPN
> is usually simple. Possibly also configure ipv4.never-default=yes.
> 
> Check the resulting routing table (after activating the VPN) with `ip
> route` to confirm that it's right.
> 
> check that you can reach the right hosts with `ping $IP_ADDRESS` and
> `traceroute -n $IP_ADDRESS`.
> 
> 
> About DNS. If you don't enable split DNS (either dns=dnsmasq or
> dns=systemd-resolved in `man NetworkManager.conf`), then all DNS
> servers are equal. In that case, you probably would want that the DNS
> server via the VPN is always consulted, because the public DNS server
> cannot resolve internal names. You'd do that by setting ipv4.dns-
> priority to a negative value.
> 
> If you have split DNS, the search domains act like "routes" for
> lookups. In that case, you can have company.com search domain via the
> VPN and the default otherwise. Again, ipv4.dns-priority may also be
> relevant in that setup...
> 
> 
> 
> 
> best,
> Thomas

Hi Thomas,

Thanks for the tip regarding DNS/routing. I've been able to set up split DNS as
you alluded via systemd-resolved, and now I'm able to resolve domains based on
the `dns-search` nm setting. Now my only gripe with the current setup is that
company.com traffic is still routed through my router, even after it's been
resolved by the tun0.

I've been able to add the subnet(s) behind the VPN as 'routes' to the VPN
connection profile, but these addresses are ephemeral and most likely be
replaced at some point. Is there a better way to manage the routed traffic?
Right now I'm manually updating the list of IP addresses as routes of the VPN
connection profile, but I'm hoping there's a better way

Thanks in advance,

Regards,
Chris
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEss2dENO/PTuA9NTTOdNgxkl4+QMFAmAcUsQACgkQOdNgxkl4
+QNcMg//YZISu8fDdMv693pF0zbrYUaeE6Ak6P3TQs20nE2bNSBwVAW3ug+RXdEf
N9mQttDyr7ao1lGzTQ4/9TKJIasaa3GyfF8t7YEvIVsm31sQFeKDtKHIewztitWK
TvjDf09+CRiaVkpTE1Dn0vmp8jH+DCxb3molBfw3AEDTHQDEpg87ZBxK72YSpzU/
ruH2e6WpftO5vZ/vUSZR7j4iKISpLz91Mfb75YnYl3bEjU/NmgS7qJA+6rFLnCo/
ExH1FlXW2/Y4A3hBi/gTBOEbdLAihrvCifktdrkem0+VAs+kjj+8l/XxxrzPifas
WMb/OZzkrS0gdKSByNb4eDFvyWcEQYK1p52q2SCFBFPStg2NH2fyIgKZ1173pONZ
ayTVm5Y+t6jF2wUR7Q0d+EATWWvalZvGEtdL6RJgdrhawTo8spQ2h/YjclpoauHH
IUsguRyStmI/SYE/PpiPEhwatee84/EwuJ5mq1YDkKLbxNdYiN9f8MRULQMoxhBa
GI9pJTuOSBAOnvfT12deCQmCLf35L5YOvc/GRAW0FkP0U3CvTRku8cPjgoWwx07L
Z16A69b1g6hJP8Fe0uNBGvhuJBFcLnbM+VVpVfplpSn7h6fwdyIts7lmfK8f30UD
c8i0twnTyEk6wWMrPejztJDNzhsXvVsjn0fp3OUkGIJHfEaX+dQ=
=V4pd
-----END PGP SIGNATURE-----

_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to