MacOS Client does not create valid Routes

[arcreigh]

Client version 0.4.0 (Intel Based Mac)
MacOS: 12.7.1

On a native wireguard app installation correct routes are created on tunnel standup, such as your default route out to the tunnel.

default link#21 UCSg utun7

However when looking at the routes created when Defguard is spun up no such routes are created.
Instead we have invalid routes such as the following.

0/1 utun7 UScg utun7
192.168.0.2 192.168.0.2 UH utun7
128.0/1 utun7 USc utun7

No "normal" default route has been created and instead a routing loop is created. The client stands up 2 routes to cover the default range rather than just using a default route and states traffic coming from the tunnel goes back out over the tunnel...

I would expect a proper default route be installed for traffic on the laptop to go over the tunnel however this does not occur.

I am using hotspot off of my phone and would expect that interface gets a default route instead of this odd split route behavior.

[teon]

@arcreigh to have a default route through the VPN one must define it - if it's not defined - then only the routes in the AllowedIPs are routed.

What do you have in AllowedIPs?

[arcreigh]

@arcreigh to have a default route through the VPN one must define it - if it's not defined - then only the routes in the AllowedIPs are routed.

What do you have in AllowedIPs?

0.0.0.0/0 is in AllowedIPs not a split tunnel situation.

Additionally, since this is 0.0.0.0/0 it should create a default route rather than 2 distinct routes for 0.0.0.0/1 and 128.0.0.0/1
And those routes should be sourced from an appropriate interface not from the tunnel interface.

[arcreigh]

Native Wireguard application routes. This is an unedited config taken directly from DefGuard portal.

Defguard Routes.

Defguard implementation of WireGuard routes.

[arcreigh]

Another note this is utilizing the iPhone hotspot feature built into MacOS.

[arcreigh]

Native WireGuard App version: 1.0.16 (27) [current version from app store]
Go backend version: 1e2c3e5a

[teon]

@moubctez i agree that we need to detect 0.0.0.0 in WireGuard-rs and change default route - this is the same case as ipv6 where default route is lacking.

[moubctez]

@arcreigh We followed wireguard-tools > wg-quick, see https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/darwin.bash#n356. (Some explanation: https://serverfault.com/questions/312860/why-openvpn-use-network-0-0-0-0-netmask-128-0-0-0-as-a-default-route).

[arcreigh]

@moubctez I understand the logic behind the decision. But from a networking standpoint it doesn't make sense to do so unless you have a reason to send half of the default one direction and the other half in another direction. In this scenario it is much more efficient to just use your standard 0.0.0.0/0 default route and filter it via the interface simplifying your implementation by only having to manage 1 route instead of 2.

The bigger issue at play here is that the current implementation does not correctly specify the source interface for these routes making the DefGuard client unusable on MacOS.

If you decided to stick with the split default you'd still need to fix the source interface on the 2 routes.

The routes define utun7 (wireguard) as the source and the destination interface causing a routing loop. Because of this behavior traffic coming into the clients tunnel from DefGuard Server will be routed back to the DefGuard Server instead of to the OS, the DefGuard server will then send it back as it should as the destination is the Client (rinse and repeat until packet TTL expires).

This also fails to send any traffic out the tunnel. The work around is to just use the native wireguard application which does correctly define the interfaces on the routes and they (Wireguard team) also opted for a single 0.0.0.0/0 route instead of the split routes.

[Juoper]

Same problem here, native mac client isn't working for me, wireguard profile is working