MacOS IPv6 not functioning without custom static route

[Adam Cooper]

I'm using the latest MacOS client and have all the appropriate stuff
setup on my server (Ubuntu 18.04) to use NAT IPv6. This works for all
my other devices (android, ios, windows) in that I can access IPv6
only sites just fine.

But on my Mac I'm unable to reach IPv6 destinations that are not on
the VPN IPv6 network.

AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4,
32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6,
172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9,
173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11,
192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14,
192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6,
200.0.0.0/5, 208.0.0.0/4, ::/0, fd82:88::1/128

Should push all traffic correctly (the final local IPv6 route being
redundant I know).

What I'm finding is that the Wireguard client is creating a new tunnel
(utun1) and using that for all the defined routes in IPv4 but it is
not setting a default route for IPv6.

My system (and I don't really know why) has a preexisting tunnel
(utun0) which is set as default

default                          fe80::%utun0                 UGcI
     utun0

Wireguard is not creating a new default route pointing at utun1. If I
do that manually

sudo route add -inet6 ::/0 fe80::%utun1

Then everything works as expected.

The only thing I can think of is that Wireguard is seeing the existing
tunnel and that it is default and assuming it does not need to create
a route, even though that route is for a tunnel that Wireguard is not
responsible for. Is this a bug? What can I do?

Probably worth mentioning that I tried to replace ::/0 with ::/1,
8000::/1 but that just results in completely broken connectivity in
IPv6 and IPv4 - which may be another issue in and of itself.