Enabling IPv6 in WireGuard alongside IPv4 (dual-stack) is increasingly essential for modern networks. Whether you’re a site operator, enterprise administrator, or developer deploying private networks, this guide provides a practical, detail-rich walkthrough to configure WireGuard with IPv6 support. You’ll get concrete configuration snippets, kernel and routing considerations, firewall recommendations, and troubleshooting tips to ensure a robust dual-stack environment.

Why run WireGuard with IPv6?

IPv6 adoption offers a number of technical advantages: abundant address space, simplified routing for many-to-many tunnels, and native end-to-end connectivity without carrier-grade NAT. For WireGuard, IPv6 also reduces address planning friction when connecting many peers, and can simplify policy-based routing because you avoid IPv4 address exhaustion workarounds. Running a dual-stack configuration allows existing IPv4-dependent services to continue while enabling modern IPv6 connectivity.

High-level architecture and address planning

Before diving into configuration, determine how IPv6 addresses will be assigned:

• Provider-supplied /64 per link or routed /48 (or /56) prefix delegation (PD) from your upstream ISP.
• Use Unique Local Addresses (ULA, fc00::/7, commonly fd00::/8) for internal-only networks if public IPv6 is not available.
• Decide if WireGuard peers receive unique /128s or if you’ll route an entire routed prefix down the WireGuard peer and use internal addressing (more complex).

For this guide we’ll use a simple and common model: the WireGuard server advertises and routes a set of IPv6 /128 addresses to peers (e.g., 2001:db8:100::/64 as the routed prefix), and the server itself has a link address and forwarding enabled. Example addressing:

• Server external IPv4: 203.0.113.10
• Server external IPv6 (link): 2001:db8::10/64
• WireGuard server tunnel IPv4: 10.66.66.1/24
• WireGuard server tunnel IPv6: 2001:db8:100::1/64
• Peer tunnel IPv4: 10.66.66.2/32
• Peer tunnel IPv6: 2001:db8:100::2/128

Kernel & sysctl prerequisites

Ensure the Linux kernel supports WireGuard (built-in since 5.6 or via module) and IPv6 forwarding is enabled. On the server:

Enable IP forwarding:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

Make persistent changes in /etc/sysctl.d/99-sysctl.conf or /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Check per-interface settings for accept_ra and proxy_nd if you use delegated prefixes.

WireGuard configuration basics (server & peer)

WireGuard configuration is straightforward. Use wg-quick or raw wg and ip commands for greater control. Below are sample wg-quick-style configs. Note the Address field includes both IPv4 and IPv6 addresses (or only IPv6/IPv4 if you prefer):

Server: /etc/wireguard/wg0.conf

[Interface] Address = 10.66.66.1/24, 2001:db8:100::1/64
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

PostUp = sysctl -w net.ipv6.conf.all.forwarding=1; ip -6 route add 2001:db8:100::/64 dev %i
PostDown = ip -6 route del 2001:db8:100::/64 dev %i

Peer: /etc/wireguard/peer1.conf (client-side)

[Interface] PrivateKey = PEER1_PRIVATE_KEY
Address = 10.66.66.2/32, 2001:db8:100::2/128
DNS = 2001:4860:4860::8888 8.8.8.8

Notes:

• Using AllowedIPs = ::/0 for IPv6 routes all IPv6 traffic via the tunnel; for split-tunnel, specify only the wanted prefixes.
• Assigning /128 IPv6 to peers is normal. The WireGuard server routes these via the tunnel interface rather than using RA inside the tunnel.

Routing and forwarding considerations

WireGuard does not implement NAT by default for IPv6 (and IPv6 NAT is discouraged). To allow peers to access the internet over IPv6, the server must have a globally routable IPv6 and the upstream router must route the peer addresses/prefix through the server. Common approaches:

• If your ISP provides a routed prefix, delegate a subtree (e.g., a /64 or /56) to the WireGuard server, and configure routes so that the server routes traffic for 2001:db8:100::/64 locally.
• If you only have one IPv6 address, you can SNAT/MASQUERADE IPv6 with nftables (supported) but it’s considered non-idiomatic. Prefer routing when possible.

Example to add a route on the upstream router (if you control it):

ip -6 route add 2001:db8:100::/64 via 2001:db8::10 dev eth0

Firewall with nftables (IPv4 + IPv6)

Use nftables for a unified firewall. Below is a minimal server-side example that accepts WireGuard and forwards traffic for IPv6:

table inet filter {
chain input { type filter hook input priority 0; policy drop;
iif "lo" accept
ct state established,related accept
udp dport 51820 accept # WireGuard port

ip6 nexthdr icmpv6 accept
}
chain forward { type filter hook forward priority 0; policy drop;
iif "wg0" oif "eth0" accept
iif "eth0" oif "wg0" accept
}
}

If you must NAT IPv6 (again, not recommended), you can use nftables’ masquerade target:

table ip nat {
chain post { type nat hook postrouting priority 100;
oifname "eth0" ip6 saddr 2001:db8:100::/64 masquerade
}
}

MTU and fragmentation

WireGuard encapsulates packets which reduces the effective MTU. For IPv6 this is important because fragmentation behavior differs from IPv4 (IPv6 relies on end-host fragmentation using Path MTU Discovery). If you experience connectivity issues, reduce the MTU on the WireGuard interface on both sides. Common values:

• Default MTU: 1420 — works for most environments (Ethernet 1500 – 60 bytes overhead).
• Test with ping6:

ping6 -M do -s 1232 2001:4860:4860::8888

Adjust wg0 MTU:

PostUp = ip link set mtu 1420 dev %i

DNS, privacy addresses, and RA considerations

IPv6 privacy addresses can be enabled on clients for outgoing connections to avoid exposing stable EUI-64 addresses. However, when you want consistent client addresses (for firewall rules, logging, or RADIUS), disable temporary addresses and use stable static /128s in the WireGuard config. For DNS, push IPv6 DNS servers in the client config (Address + DNS in wg-quick).

Router Advertisements (RA) and SLAAC usually apply to LANs, not tunnel endpoints configured with /128s. If you decide to route an entire prefix over a WireGuard peer and then use SLAAC on the remote LAN behind that peer, you’ll need to:

• Enable proxy NDP or NDisc on the WireGuard server (e.g., ndppd or use nftables helper) so the server answers neighbor solicitations.
• Ensure proper RA daemon (radvd or systemd-networkd) runs on the remote host to advertise addresses on the LAN interface.

Troubleshooting checklist

• Verify WireGuard status: wg show; check handshake times and transfer counters.
• Check IPs: ip addr show dev wg0 and ip -6 route show.
• Confirm IPv6 forwarding: sysctl net.ipv6.conf.all.forwarding.
• Check neighbor tables: ip -6 neigh for NDP entries.
• Use packet capture: tcpdump -i wg0 ip6 to see encapsulated vs inner packets.
• If no internet access for IPv6: check upstream routes and whether upstream router is dropping routed prefixes.

Advanced topics

Prefix Delegation to multiple peers

When you have a routed block (e.g., /48), you can allocate /64s to different peers. Configure the server to add routes directing each delegated /64 to the appropriate peer’s tunnel endpoint. This approach allows full subnets behind peers, enabling SLAAC on remote LANs.

Policy-based routing

On servers with multiple uplinks, you can use source-based routing to steer IPv6 flows. Create separate routing tables and ip -6 rule entries to make sure return traffic leaves through the expected upstream link matching the source IPv6 prefix.

Integration with orchestration

For cloud or container environments, wireguard interfaces can be provisioned dynamically. Keep in mind that IPv6 ULA prefixes are stable across instances only if orchestrated centrally; use a controller (e.g., Terraform + cloud-init) to assign consistent global or ULA addresses.

Security best practices

• Rotate keys if a peer is compromised; WireGuard makes key replacement straightforward.
• Use minimal AllowedIPs on each peer to limit lateral movement (e.g., only the specific routed IPv6 and necessary services).
• Harden the host firewall and monitor logs for unusual ND/ICMPv6 activity.

Wrapping up, a practical WireGuard dual-stack deployment requires planning for addressing and routing, enabling IPv6 forwarding, careful firewall configuration, and attention to MTU and NDP behavior. With the patterns above you can support both IPv4 and IPv6 peers reliably and securely. For more implementation examples and managed dedicated-IP solutions, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.