* MacOS IPv6 not functioning without custom static route
@ 2020-07-15 12:14 Adam Cooper
2020-07-21 13:12 ` Hasan Berkay Çağır
0 siblings, 1 reply; 7+ messages in thread
From: Adam Cooper @ 2020-07-15 12:14 UTC (permalink / raw)
To: wireguard
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-15 12:14 MacOS IPv6 not functioning without custom static route Adam Cooper
@ 2020-07-21 13:12 ` Hasan Berkay Çağır
2020-07-21 13:29 ` Adam Cooper
0 siblings, 1 reply; 7+ messages in thread
From: Hasan Berkay Çağır @ 2020-07-21 13:12 UTC (permalink / raw)
To: Adam Cooper; +Cc: wireguard
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-21 13:12 ` Hasan Berkay Çağır
@ 2020-07-21 13:29 ` Adam Cooper
2020-07-21 13:49 ` Hasan Berkay Çağır
2020-07-21 13:50 ` Adam Cooper
0 siblings, 2 replies; 7+ messages in thread
From: Adam Cooper @ 2020-07-21 13:29 UTC (permalink / raw)
To: Hasan Berkay Çağır; +Cc: wireguard
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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-21 13:29 ` Adam Cooper
@ 2020-07-21 13:49 ` Hasan Berkay Çağır
2020-07-21 13:58 ` Adam Cooper
2020-07-21 13:50 ` Adam Cooper
1 sibling, 1 reply; 7+ messages in thread
From: Hasan Berkay Çağır @ 2020-07-21 13:49 UTC (permalink / raw)
To: Adam Cooper; +Cc: wireguard
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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-21 13:29 ` Adam Cooper
2020-07-21 13:49 ` Hasan Berkay Çağır
@ 2020-07-21 13:50 ` Adam Cooper
1 sibling, 0 replies; 7+ messages in thread
From: Adam Cooper @ 2020-07-21 13:50 UTC (permalink / raw)
To: Hasan Berkay Çağır; +Cc: wireguard
As an additional datapoint it looks like if I remove '::/0' at all
(either replaced with the ::/1 8000:/1 rules or just removed outright)
I appear to lose outbound traffic UNLESS I'm allowing 0.0.0.0/0. Which
doesn't make much sense as one is an IPv4 rule and the other isn't.
This is what it currently look like (pseudocode for brevity)
$IPV4_IPS = 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
AllowedIPs = $IPV4_IPS, ::/0, fd82:88::1/128 -- IPv4 WORKS, IPv6 ONLY
ROUTES fd82:88::1
AllowedIPs = $IPV4_IPS, fd82:88::1/128 -- IPv4 AND IPv6 DO NOT WORK
AllowedIPs = $IPV4_IPS, ::/1, 8000::/1, fd82:88::1/128 -- IPv4 AND
IPv6 DO NOT WORK
AllowedIPs = 0.0.0.0/0, ::/1, 8000::/1 -- IPv4 AND IPv6 WORK
On Tue, 21 Jul 2020 at 14:29, Adam Cooper <adam@acpr.dev> 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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-21 13:49 ` Hasan Berkay Çağır
@ 2020-07-21 13:58 ` Adam Cooper
2020-07-21 14:03 ` Hasan Berkay Çağır
0 siblings, 1 reply; 7+ messages in thread
From: Adam Cooper @ 2020-07-21 13:58 UTC (permalink / raw)
To: Hasan Berkay Çağır; +Cc: wireguard
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@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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MacOS IPv6 not functioning without custom static route
2020-07-21 13:58 ` Adam Cooper
@ 2020-07-21 14:03 ` Hasan Berkay Çağır
0 siblings, 0 replies; 7+ messages in thread
From: Hasan Berkay Çağır @ 2020-07-21 14:03 UTC (permalink / raw)
To: Adam Cooper; +Cc: wireguard
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@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@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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-07-21 14:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-15 12:14 MacOS IPv6 not functioning without custom static route Adam Cooper
2020-07-21 13:12 ` Hasan Berkay Çağır
2020-07-21 13:29 ` Adam Cooper
2020-07-21 13:49 ` Hasan Berkay Çağır
2020-07-21 13:58 ` Adam Cooper
2020-07-21 14:03 ` Hasan Berkay Çağır
2020-07-21 13:50 ` Adam Cooper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).