Re: wg-quick IPv6 same route on different interfaces

Re: wg-quick IPv6 same route on different interfaces

[Brian Candler]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

> I'm setting up an WireGuard tunnel between my VPS and my home network. This
> tunnel should be IPv6 only.
> I assigned the IPv6 subnet fd00:1:a/64 to my home network and my wireguard
> client got the static IP fd00:1:a::1.
> On the VPS I assigned the IP fd00::1 to the wg0 interface.
>
> Here're the configs:
> *Client:*
>
>> [Interface]
>> PrivateKey = XXXX
>> Address = fd00:1:a::1/64
>> [Peer]
>> PublicKey = XXXX
>> AllowedIPs = fd00:0:0::/64
>> EndPoint = vpn.domain.tld:51820
>> PersistentKeepalive = 25
> Server:
>
>> [Interface]
>> PrivateKey = ...
>> ListenPort = 51820
>> Address = fd00:0:0::1
>>
>> [Peer]
>> PublicKey = XXXX
>> AllowedIPs = fd00:1:a::/64
It *might* work if at the client side you use

Address = fd00:1:a::1

instead of

Address = fd00:1:a::1/64

However, the safest way to make it work is for the [Interface] Address 
at each end to be a separate point-to-point subnet.  These are the 
addresses allocated to the wg0 interface itself.  I don't know if 
"unnumbered" point-to-point links are supported by Wireguard (that is, 
when you re-use an address from a subnet that belongs to a different 
interface), but I know it definitely works with a separate link subnet.

So if you want to use the whole block fd00:0:0::/64 in your VPS, then I 
suggest you allocate a new subnet for the point-to-point, e.g.

client

[Interface]
Address = fd00:2::2/64

server

[Interface]
Address = fd00:2::1/64

AllowedIPs are then still the remote subnets at each side, as you have now.

If your VPS is just a single host with a single IPv6 address on the wg0 
interface, then you can keep it as you have now but use

server

[Interface]
Address = fd00:0:0::1/64

client

[Interface]
Address = fd00:0:0::2/64

HTH,

Brian.

[-- Attachment #2: Type: text/html, Size: 2640 bytes --]

wg-quick IPv6 same route on different interfaces

[Waishon]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

Hey there,

I'm setting up an WireGuard tunnel between my VPS and my home network. This
tunnel should be IPv6 only.
I assigned the IPv6 subnet fd00:1:a/64 to my home network and my wireguard
client got the static IP fd00:1:a::1.
On the VPS I assigned the IP fd00::1 to the wg0 interface.

Here're the configs:
*Client:*

> [Interface]
> PrivateKey = XXXX
> Address = fd00:1:a::1/64
> [Peer]
> PublicKey = XXXX
> AllowedIPs = fd00:0:0::/64
> EndPoint = vpn.domain.tld:51820
> PersistentKeepalive = 25


Server:

> [Interface]
> PrivateKey = ...
> ListenPort = 51820
> Address = fd00:0:0::1
>
> [Peer]
> PublicKey = XXXX
> AllowedIPs = fd00:1:a::/64


After running "wg-quick up wg0" I'm able to ping the Server and the Server
is able to ping the client.
However I'd like to reach all my clients in my home network. To do this I
added a static route that forwards all traffic addressed to fd00::/64 to my
wireguard client machine (fd00:1:a::1) and enabled IP-Forwarding on the
client. When I now do a ping6 from my VPS to another client in my network I
only get an unreachable error.

Some further debugging shows that wireguard adds another route for my homes
fd00:1:a::/64 network. Without wireguard I only have the "fd00:1:a::/64 dev
wlan0" route.

*IP -6 route show:*
fd00::/64 dev wg0 metric 1024  pref medium
fd00:1:a::/64 dev wlan0 proto kernel metric 256  expires 6993sec pref medium
fd00:1:a::/64 dev wg0 proto kernel metric 256  pref medium

Because it prioritizes the route where the packet comes from the packet is
routed back to WireGuard which obviously don't know what to do with,
because it's not configured as AllowedIPs.

After manually removing the duplicate route entry everything works as
expected and I'm able to ping all my clients in my network from the VPS.

A friend of my has setup WireGuard to use IPv4 only. IP route doesn't show
anly duplicate routes there.

I were able to reproduce this error on two wireguard client machines.

Do I miss something in the configuration or is this a bug?

Kind regards
Soeren

[-- Attachment #2: Type: text/html, Size: 2912 bytes --]