apple
apple copied to clipboard
eduvpn
"excluded routes" does not work
When configuring the eduVPN server for sending all traffic over the VPN, except a few destinations, it doesn't work on macOS. It does work properly on Windows. Tested it with both the macOS eduVPN and WireGuard apps. It is broken in both. So I guess it is an 'upstream' WireGuard issue, but not sure how/where to report this.
You can test it yourself with https://vpn-next.tuxed.net and the "Excl. Routes" profile. All traffic SHOULD be routed over the VPN, except traffic to v6.de. So if you visit v6.de it should show your home ISP network, but if you for example visit myip.tf it should show the VPN addresses.
https://github.com/eduvpn/documentation/blob/v3/PROFILE_CONFIG.md#exclude-route-list
I had the same problems on Windows with Wireguard.
Configexample:
'defaultGateway' => true, 'excludeRouteList` => ['192.168.0.0/16'],
did not work on Windows 10. When checking routes with route print there were a lot of routes which should work, but there also was this 0.0.0.0 default route which was the culprit for blocking access to 192.168.178.1 which is also the default gateway by the way.
Using 'defaultGateway' => false, 'routeList' => [ '0.0.0.0/1', '128.0.0.0/1', '::/1', '8000::/1' ], basically also routes everything through the VPN except local traffic. Adopted from https://techjourney.net/how-to-allow-local-network-when-using-wireguard-vpn-tunnel-in-windows-10/
@JsBergbau this issues tracker is for iOS/macOS, not Windows. Could you report this for Windows? https://github.com/Amebis/eduVPN/issues
@fkooman I think something is wrong with the computation of AllowedIPs. I tried modifying the AllowedIPs to just:
AllowedIPs = 45.77.162.182/32, 9.9.9.9/32
(45.77.162.182 == myip.tf, 9.9.9.9 == dns server to resolve myip.tf)
When I activate this in the WireGuard app for macOS, only the connection to myip.tf is routed through the tunnel. Everything else goes outside of the tunnel.
bash-3.2$ curl myip.tf
103.254.128.114
bash-3.2$ curl v6.de/ip.html
your IP address is: 103.254.128.114 ((none))
bash-3.2$ scutil --nc start "only-myip-tf" # start VPN
bash-3.2$ curl myip.tf
145.220.52.206
bash-3.2$ curl v6.de/ip.html
your IP address is: 103.254.128.114 ((none))
bash-3.2$ scutil --nc stop "only-myip-tf" # stop VPN
bash-3.2$ curl myip.tf
103.254.128.114
bash-3.2$ curl v6.de/ip.html
your IP address is: 103.254.128.114 ((none))
bash-3.2$
@fkooman:
When using the excl-rt configuration downloaded from the web portal in the WireGuard app, the tunnel doesn't transfer any data. When I modify the AllowedIPs to 0.0.0.0/0, it works. So I assume something is wrong with the AllowedIPs.
wg-quick config doesn't have support for excluded routes directly. I presume the eduVPN server figures out the AllowedIPs based on the excludeRouteList that it as been configured with.
Therefore, I think the problem might have been with how AllowedIPs is computed.
We can consider the option of the server communicating the excludedRouteList to the client outside of the wg-conf file. Is that something we would want to explore?
Therefore, I think the problem might have been with how AllowedIPs is computed.
Can you point out the issue with the calculation? There are unit tests for it, and I compared it with how Go calculates those...
https://git.sr.ht/~fkooman/vpn-user-portal/tree/v3/item/tests/IpNetListTest.php
We can consider the option of the server communicating the excludedRouteList to the client outside of the wg-conf file. Is that something we would want to explore?
Wouldn't fixing that solve the same problem as making the configuration file work?
Can you point out the issue with the calculation?
The calculation does seem correct. The routing table looks correct too. I'm not sure yet why the tunnel isn't working.
Wouldn't fixing that solve the same problem as making the configuration file work?
Yes. It's another way of addressing the issue (more complicated though, I admit). Let's first try to figure out what the problem is in the config file way.
The first route in the AllowedIPs for the "Excl. Routes" profile is: 0.0.0.0/1
It appears that macOS doesn't like the corresponding entry in the routing table. If I replace "0.0.0.0/1" in AllowedIPs with "1.0.0.0/8, 2.0.0.0/8, 3.0.0.0/8, ..., 127.0.0.0/8", the tunnel seems to work as intended (with only v6.de routed outside the tunnel). I'm not sure why this is the case.