WireGuard on macOS sets default route when it shouldn't

[Thomas Keppler <winfr34k@gmail.com>]

Hello everyone,

on a remote system I administer, I have setup a WireGuard VPN. All in all, this process has worked swimmingly. However, I have got one big issue on all of my macOS clients and I'm not sure if it's a bug or if it's me just using the software aka holding it wrong.

I am not quite sure if this Mailing List is the right place to bother with questions like this, but I will try my luck anyways :-)

Given a client configuration like so:
------------ 8< ------------
[Interface]
PrivateKey = <privkey>
Address = 192.168.1.1/32
DNS = 192.168.0.253
MTU = 1420

[Peer]
PublicKey = <pubkey>
PresharedKey = <psk>
AllowedIPs = 192.168.0.0/24, 192.168.1.254/32
Endpoint = <endpoint>:51820
------------ >8 ------------

When I activate the tunnel connection, I always get several routes pushed, all of which are OK except the default route:
------------ 8< ------------
default via link#19 dev utun6
192.168.0.0/24 dev utun6  scope link
192.168.1.1/32 via 192.168.1.1 dev utun6
192.168.1.254/32 dev utun6  scope link
224.0.0.0/4 dev utun6  scope link
255.255.255.255/32 dev utun6  scope link
------------ >8 ------------

From what I have read so far on other forums, Reddit, StackOverflow and such, the specific "AllowedIPs" I'm supplying should prevent the default route from being pushed. I have also tried to locate the code responsible for pushing these routes, but so far I could only gather that a "routeSocket" is established and watched in the Go internals that seems to be only read. The macOS app also does not seem to modify this socket (or any part I have read so far).

So given all of this, I have got two (main) questions (and an aside):

1.) Am I using WireGuard just plainly wrong or is it a Bug/Known Issue?
2.) Where is the code responsible for pushing routes?
3.) ...and what are good resources to check to get a better understanding of how this works internally?

Thank you very much for any response to this message in advance. I cannot wait to figure this one out!

--
Sincerely
Thomas Keppler