GNOME.org
 

Re: Trouble converting full OpenVPN tunnel to split tunnel

-----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-----
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]