Howto use IPv6 with Wireguard

Hello Community,
i have setup a Wireguard server some months ago and it is working fine as long as the clients are connecting via IPv4. The problem is quite obvious because my WG0 interface on my OpenWRT-Wireguard-Server has no IPv6 address.

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr ''
	option netmask ''

config globals 'globals'
	option ula_prefix 'fdb0:1474:eef6::/48'

config interface 'lan'
	option ifname 'eth0.1'
	option force_link '1'
	option macaddr 'XXXXXXXXXXXXXXX'
	option type 'bridge'
	option proto 'static'
	option netmask ''
	option ip6assign '60'
	option ipaddr ''

config interface 'wan'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'pppoe'
	option username ''
	option password ''
	option ipv6 'auto'
	option peerdns '0'
	option dns ''
	option keepalive '0'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'
	option dns '2606:4700:4700::1111'

config switch
	option name 'switch0'
	option reset '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 6t'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6t'
	option vid '2'

config interface 'WG0'
	option proto 'wireguard'
	option private_key ''
	option listen_port '51902'
	list addresses ''
	option mtu '1400'

config wireguard_WG0
	option route_allowed_ips '1'
	option public_key 'XXXXXXXXXXXXX'
	option description 'lyfinSD'
	list allowed_ips ''
	list allowed_ips ''
	list allowed_ips '::/0'

I get an IPv6-IP from my ISP which looks like this:

This address is the one DDNS changes at my provider dynv6:
IPv6: 2003:c7:4fff:3f8f:9099:2511:a886:fdc1/64

My internal clients are already getting addresses from

IPv6-PD: 2003:c7:4f3f:4800::/56

like 2003:c7:4f3f:4800::a01/128

Question is what address should i enter for the Wireguard server and the client? The IPv6-PD i got now changes every time i reconnect.


My main goal is to connect another Debian client from elsewhere to use some services provided in

WireGuard doesn't support dynamic addresses inside the tunnel.
If you have a static prefix, then just split a /64 and delegate it to the VPN.
Otherwise, you can utilize a ULA prefix with NAT6, or set up a tunnel broker and use its static prefix.

1 Like

Then ULA (private) addresses will do just fine.
However I noticed that you allow and route and ::/0 to the client. Is that correct? Are you accessing the internet from your client?

1 Like

Yes i do sometimes, to prevent hijacking in open networks :).

Ok so what is the story about this ULA and how to configure it? Im sorry for asking simple questions, but this IPv6 thing is quite new to me :).

WireGuard configuration examples

If the client needs to access the internet via the OpenWrt wireguard server, then you got it wrong here.
The way you have it is that all traffic from OpenWrt will be routed via the Wireguard client.
This might not actually happen if you have assigned proper metrics but still it is wrong.
To force the client to use the internet from OpenWrt, then the 0/0 and ::/0 must be added in the config of the client.


Given that you do need to hardcode the IPv6 addresses in your client configuration, you're in sort of a pickle with dynamic IPv6 prefixes… One option would be to use a Hurricane Electric tunnel just for this purpose, to get a static prefix for VPN uses (only).

1 Like

I don't think it really requires support in the WireGuard protocol. I tried using DHCPv6 between two OpenWrt devices and it did assign IPv6 addresses. The only thing that's missing is updating WireGuard's AllowedIPs with the assigned addresses (or prefixes). (Obviously it's a bit harder to implement it on a device that doesn't allow you to run code as root, i.e. Android etc.)

1 Like

So im confused now. The problem is that my ISP is giving me a IPv6-PD/56 which changes. OpenWRT shares already this addresses to my local network with a /64 prefix. So my clients getting the right addresses for having fun in the internet, right?

The thing is now that these IPv6-PD which im getting from the Telekom is constantly changing and Wireguard does not support this.

I do have an ULA prefix pre configured in OpenWRT which has "fdb0:1474:eef6::/48" and my local clients are also getting addresses in this network.

Now if i understand that right i have to assign my WG-Server an address from this ULA prefix like


and the peers will go with fdb0:1474:eef6:1234:2::/48 and so on. So OpenWRT would do the routing because it "knows" about the changing /56 thing from the Telekom and the ULA addresses. But then there is NAT6 which i haven´t understood what it is for in this scenario.

Wow thanks a lot for this! I will try to understand it fully before just copy pasting it.

One thing is not very clear to me, so please forgive me question:

The address
is due to the /64 prefix a legit "subnet" as well as
right? Im not 100% sure if i understood this right in this whole ipv6 thing. Is in this case every IPv6 address beyond fdb0:1474:eef6:1234:.... a legitimate one because it comes with that prefix?

A /64 prefix is typically enough for a VPN subnet, you can validate it here:

Sorry for bringing this old topic up again, but i have finally solved this issue right now.

Here´s what i have done, according to

added this

config dhcp 'lan'
     option dhcpv6 relay
        option ra relay
        option ndp relay

and this

config dhcp 'wan6'
    option dhcpv6 relay
    option ra relay
    option ndp relay
    option master 1
    option interface wan6

after that i edited the WG interface under advanced settings i set IPv6 assignment length to 64 and IPv6 prefix filter to wan6. After that i restarted the dhcp-service and now i can see that the WG interface has got an IPv6 address. Linux clients are now using the IPv6 address for default. This is working for me now. My ISP is the Deutsche Telekom.

Maybe this helps someone else too.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.