MacOS IPv6 not functioning without custom static route

Hasan Berkay Çağır berkay at cagir.me
Tue Jul 21 16:03:57 CEST 2020


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 <adam at acpr.dev> 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 <berkay at cagir.me> 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 <berkay at cagir.me> 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



More information about the WireGuard mailing list