"split tunnel" does not work
fkooman opened this issue · 12 comments
I created a "split tunnel" profile on vpn.tuxed.net that only pushes some routes to the client, i.e. forces the client to use the VPN only for those addresses, and route everything else outside the VPN tunnel, in this case the addresses associated with v6.de should be routed over the tunnel.
When connecting to this profile, one would expect to be able to go to v6.de and see the IP addresses of the VPN server (because NAT is used on the VPN server).
What happens is that DNS does not work at all. Only disconnecting the VPN makes DNS work again.
I tested it with the latest version of Tunnelblick and there everything* works as expected.
*There is a bug in Tunnelblick where it doesn't pick up IPv6 DNS addresses, it then? doesn't query for AAAA records
I'm afraid I have no idea what is needed to facilitate this. It sounds more like something that openvpn should take care of, or is this something to setup in the up script? If so, how? Or some command from https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt missing implementation perhaps?
It has to do with configuring the routes. How is that currently done with the default gateway? You manipulate the default gateway using the up/down scripts? It does work in Tunnelblick so you can have a look at how they handle routing table entries there...
Our up/down scripts are slightly adjusted copies of the Tunnelblick scripts.
Are you able to reproduce the problem yourself with vpn.tuxed.net and the "Split Tunnel" profile? You should have access to v6.de over the VPN, but other destinations should go outside the tunnel.
so v6.de should show you the IPv6 and IPv4 address of the VPN server, but e.g. ifconfig.co should show you your own IP.
Indeed DNS stops working when connected via "Split Tunnel" profile. It seems the DNS servers are set according to the message from openvpn:
Sat Nov 24 12:14:10 2018 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.197.90.1,dhcp-option DNS fdf8:e0f:1937:c633::1,explicit-exit-notify 1,route 104.16.16.96 255.255.255.255,route 104.16.17.96 255.255.255.255,route 104.16.18.96 255.255.255.255,route 104.16.19.96 255.255.255.255,route 104.16.20.96 255.255.255.255,route 195.30.8.34 255.255.255.255,route-ipv6 2001:608:0:1007::1:34/128,route-ipv6 2001:608:0:1007::34/128,route-ipv6 2606:4700::6810:1060/128,route-ipv6 2606:4700::6810:1160/128,route-ipv6 2606:4700::6810:1260/128,route-ipv6 2606:4700::6810:1360/128,route-ipv6 2606:4700::6810:1460/128,tun-ipv6,route-gateway 10.197.90.1,topology subnet,ping 25,ping-restart 150,ifconfig-ipv6 fdf8:e0f:1937:c633::1000/112 fdf8:e0f:1937:c633::1,ifconfig 10.197.90.2 255.255.255.192,peer-id 0,cipher AES-256-GCM'
I am not quite clear how the script should know to keep the existing DNS settings in this case (should it?), or what to do differently.
It is an interesting case actually, and maybe my fault! If the "split tunnel" configuration pushes DNS servers, but those same DNS servers are not routed over the VPN, then obviously it won't work! So maybe what is needed is that I also push routes for reaching the DNS servers to the client!
But this shouldn't be an issue in this case as the DNS IP addresses are actually the IP addresses of the "internal" VPN gateway, so this should work without issue I think!
Maybe we have to do something else instead and also push the "domain" for which the VPN DNS servers should be used. For example, if your LAN is using the ".local" TLD, then all requests for ".local" should go to the VPN DNS and not to your "system DNS".
It is quite complicated to get exactly right, what I don't understand is why it doesn't work in this "simple" configuration...
Output of netstat -rn:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default link#11 UCS 44 0 utun1
default 192.168.178.1 UGScI 12 0 en1
10.197.90/26 10.197.90.3 UGSc 1 0 utun1
10.197.90.3 10.197.90.3 UH 4 0 utun1
104.16.16.96/32 10.197.90.1 UGSc 0 0 utun1
104.16.17.96/32 10.197.90.1 UGSc 0 0 utun1
104.16.18.96/32 10.197.90.1 UGSc 0 0 utun1
104.16.19.96/32 10.197.90.1 UGSc 0 0 utun1
104.16.20.96/32 10.197.90.1 UGSc 0 0 utun1
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 194 lo0
169.254 link#7 UCS 0 0 en1
192.168.178 link#7 UCS 1 0 en1
192.168.178.1/32 link#7 UCS 1 0 en1
192.168.178.1 e0:28:6d:56:e:55 UHLWIir 14 279 en1 1196
192.168.178.156/32 link#7 UCS 0 0 en1
192.168.178.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 en1
195.30.8.34/32 10.197.90.1 UGSc 0 0 utun1
224.0.0/4 link#11 UmCS 1 0 utun1
224.0.0/4 link#7 UmCSI 0 0 en1
224.0.0.251 link#11 UHmW3I 0 0 utun1 3587
255.255.255.255/32 link#11 UCS 0 0 utun1
255.255.255.255/32 link#7 UCSI 0 0 en1
I can't ping 10.197.90.1, and why is the default route set?
It seems OpenVPN (or the helper) takes care of setting the (IPv4) routes correctly, i.e. the 104.X and 195.X routes. Those are explicitly pushed from the server... But it eagerly also sets the default gateway...
Hello, we have the same issue on our side.
With other vpn client (tunnelblick and openvpn cli) it's working like a charm
eduvpn
# netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default link#20 UCS 73 0 utun2
default 192.168.210.1 UGScI 16 0 en0
with openvpn cli or tunnelblick
# netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.210.1 UGSc 81 0 en0
It now works with 1.1, thank you!