Hi
i am trying to make a wireguard server using only IPV6 on 7.19.4 (stable)
i am unable to route the ipv6 adress when i add the IPV6 Adress to the wireguard interface…
Is there a good howto ?
HI. I was able to do it via ULA addresses and masquerading:
/ipv6 pool add name=ULA prefix=fc00::/7 prefix-length=64
/ipv6 address add address=fc00::1:0 comment=WIREGUARD-ULA interface=WireGuard
/ipv6 firewall nat add action=masquerade chain=srcnat comment=“MASQUERADE WIREGUARD ULA” in-interface=WireGuard out-interface-list=WAN src-address=fc00::/7
/interface wireguard peers add allowed-address=fc00::1:1/64
The traffic destinated to internet will then exit via one public /64 GUA address that you already should have set up.
It works but currently involves a lot of hardcoded configuration. Because if you have multiple remote peers, you can’t use SLAAC for address assignment.
-
Adding an address (with a prefix length, for example
/64) to the WG interface is a required step, but is not enough. -
You also need to give each peer a hardcoded address or subnet that is inside the subnet above in the
allowed-addressfield, and make sure that those addresses or subnets do not overlap. For example, you can give the peers individual hardcoded/128address or individual non overlapping/80subnets. Do not use the full/64prefix length if you want to have multiple peers active at the same time! -
On the remote devices, in their WG configuration, these chosen
/128addresses or larger subnets (for example/80) must of course be used as IP address in the WG config. And in the peer configuration associated with the router, use either::/0if you want to route all traffic through the router, or just the/64address range of step #1 above as well as other LAN subnets you want to give access to. -
As DNS in the WG setting on the remote device you can use the router’s address assigned in step #1 (without
/64).
Now as we can see, the steps above have a lot of hardcoded configuration that cannot be changed automatically by the router (all the WG configuration on the remote devices have hardcoded IPv6 addresses). Which means if you want to use a public IPv6 prefix issued by your ISP to assign to the WG interface as well as the devices inside the tunnel, that prefix must be a static prefix. If the ISP gives you a dynamic prefix that can change at any time, then using this directly is not practical at all.
In case the dynamic ISP only gives dynamic IPv6 prefixes, you’ll need to assign some other, static prefix to the WG interface as well as for the allowed-address of the peers, you can chose between these alternatives:
-
You choose a ULA prefix (you can go here and pick a random one Unique Local IPv6 Generator, don’t use trivial prefixes!), pick a
/64from that/48to assign to the WG interface under/ipv6 address, then issue hardcoded/128(or bigger subnets like/80if you want) to the peers (as described in #2 and #3 above). The downside is that ULA addresses have lower priority than IPv4 addresses, which means if the tunnel has both IPv4 as well as IPv6 configured, client apps might prefer IPv4 when making new connections. -
Or you go Hurricane Electric Free IPv6 Tunnel Broker and get a non-ULA
/48or/64prefix and use that instead for the WG peers and the WG interface. The prefix will not be routed to you, you just use that as a static prefix that has higher priority than ULA. Otherwise, what described under #2 and #3 still apply.
In both cases, if you want your WG peers to also be able to go out to the internet through the router, some SRCNAT will be required to translate the ULA or HE prefix to the proper public IPv6 prefix that the ISP gave you. You can either use a masquerade rule, but I prefer a action=netmap chain=srcnat rule instead, that way the interface id part (the 64-bit on the right) of the IPv6 addresses of the different peers will be different.
1 Like
How would you go about attaining auto-changing IPv6 addresses for each client that accesses the internet thru WG? If they are not being assigned by SLAAC.
I have static IPv6 /56 from ISP and have WG working with multiple clients to tunnel into the Mikrotik router network remotely, but so far I have had to hard-code per-client static /128 addresses. It works but it’s an obvious privacy/tracking problem.
I my case, like wrote above, I give the WG clients hardcoded /80 subnets (from the shared /64). So, the first 4 hex digits after the /64 part are unique per clients and are hardcoded.
Then on the client WG app you can pick whatever you want for the remaining 3×4 hex digits of the interface ID and can manually change them whenever you want in the app on the devices, without having to change the router configuration.
Example (with ULA), WG interface has fd7d:8eae:088e:24::/64 subnet.
-
Client A gets
fd7d:8eae:088e:24:1000::/80(set in the peer on the router), set in the WG app todayfd7d:8eae:088e:24:1000:a:b:c/80, tomorrowfd7d:8eae:088e:24:1000:0304:1516:2728/80or something else random for the last 48 bits. -
Client B gets
fd7d:8eae:088e:24:1001::/80(set in the peer on the router), on the device, usesfd7d:8eae:088e:24:1001:bad:beef:f00d/80now, next weekfd7d:8eae:088e:24:1001:8d:a677:6eb8/80etc...
The suffix changes only have to be made on the clients. Of course, if static GUA (like you have) is not available, then netmap SRCNAT rules are required to keep the interface ID part intact, not masquerade.
Thanks. I understand. And that works. But it’s not a good solution for multiple clients and non-tech users.
I didn’t find a solution to automatically randomize the address on e.g. Android or Windows Wireguard client. Maybe it’s possible with a script to directly edit config file.
My ISP finally went live with ipv6 at the end of last year and I’ve just got round to configuring wireguard clients with their own ipv6 configurations using your tips.
The ISP uses PPPoE for ipv4, then dhcpv6 to get a /56 prefix: all is dynamic and changes every time the PPPoE client reconnects (always due to changes on my side e.g. routeros upgrades and so on).
I’ve opted to use my /48 from HE which I was previously using to provide some ipv6 connectivity to my network, though there are well known issues with the geoblocking done by Netflix and so on which had to be worked around. If my understanding is correct, although this is ‘my’ /48, as you say it’s not being routed to me in this configuration, so could one technically ‘make up’ any /48? Given there are 1.2 septillion of them, the chances of clashing with a genuine one are quite small!
Just wanted to say thank you so much for this really useful post.