Glad to hear that, you’re welcome. There is definitely something weird happening with having ::/0 in AllowedIPs on MacOS. In my situation too that the client were generating a default IPv4 route and I had to tunnel my IPv4 too until I discovered the “::/1, 8000::/1“ trick.
Best, Berkay > On 21. Jul 2020, at 15:58, Adam Cooper <[email protected]> wrote: > > Wow. So I'd made the assumption that this is just what I needed to do > to access lan resources. > > Turns out "0.0.0.0/0, ::/1, 8000::/1" will allow that just fine on > OSX. I still get a broken system if I specify ::/0 as the default > route doesn't appear to get created but with using ::/1 8000::/1 it > seems to work around that. > > Problem solved! Thank you. > > Though it's not at all intuitive or expected. Is there some issue > queue or something this can be added to for the OSX client > application? > > Thanks > Adam > >> On Tue, 21 Jul 2020 at 14:49, Hasan Berkay Çağır <[email protected]> wrote: >> >> Are you sure that private IPs get routed through WG while AllowedIPs is >> "0.0.0.0/0, ::/1, 8000::/1"? I have just tried to ping my local router >> whilst connected to a tunnel with "0.0.0.0/0, ::/1, 8000::/1" and didn't >> have a problem. >> >> I mean, the way which makes sense is that AllowedIPs should work with >> your configuration and we wouldn't even have this conversation, however >> there are some things awkwardly different on the MacOS version from the >> GNU/Linux versions of WG client(s), so I think it might help to try >> every variation. >> >> Best, >> Berkay >> >>> On 21.07.20 15:29, Adam Cooper wrote: >>> Mmm. It looks like unticking "Exclude Private IPs" and entering >>> "0.0.0.0/0, ::/1, 8000::/1" gives me a functional setup. Trouble is I >>> don't want to route the private IPs and ticking the box (whilst >>> retaining '::/1, 8000::/1') allows no traffic at all. There's >>> something odd about the way the client is configuring routes but I've >>> not got the expertise to figure it out :( >>> >>> On Tue, 21 Jul 2020 at 14:12, Hasan Berkay Çağır <[email protected]> wrote: >>>> >>>> On 15/07/2020 14:14, Adam Cooper wrote: >>>>> ... >>>>> 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. >>>> >>>> Did you try only having "::/1, 8000::/1" in the AllowedIPs option? I had >>>> a default route creation issue myself where I'm only trying to tunnel >>>> IPv6 through; and having this actually solved it. >>>> >>>> $ netstat -nr >>>> Routing tables >>>> Internet: >>>> ... >>>> Internet6: >>>> Destination Gateway >>>> Flags Netif Expire >>>> ::/1 link#14 >>>> UCS utun2 >>>> default fe80::%utun0 >>>> UGcI utun0 >>>> default fe80::%utun1 >>>> UGcI utun1 >>>> default fe80::%utun3 >>>> UGcI utun3 >>>> default [ public IPv6 ] >>>> UGcI utun2 >>>> >>>> If just "::/1, 8000::/1" solves the IPv6 issue, I guess you can give it >>>> a try with "0.0.0.0/0, ::/1, 8000::/1" to see if both routes are created >>>> properly? >>>> >>>> Best, >>>> Berkay
