Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Adam Cooper <adam@acpr.dev>
To: wireguard@lists.zx2c4.com
Subject: MacOS IPv6 not functioning without custom static route
Date: Wed, 15 Jul 2020 13:14:39 +0100	[thread overview]
Message-ID: <CAN00TTomuZoagZF2McBkDW1ZimSouN-jnDLm+Hq7OKeH-sF9zg@mail.gmail.com> (raw)

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.

             reply	other threads:[~2020-07-21 12:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 12:14 Adam Cooper [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN00TTomuZoagZF2McBkDW1ZimSouN-jnDLm+Hq7OKeH-sF9zg@mail.gmail.com \
    --to=adam@acpr.dev \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).