A Geek with Guns - IPv6

Setup IPv6 in WireGuard

2025-12-30T15:30:00-06:00

Introduction</h1>
Over the holiday break I finished upgrading all of my self-hosted services to make them available via IPv6. The upgrade was straightforward for all of my services except one: my WireGuard VPN</abbr> server. I wanted to provide my VPN clients with IPv6 connectivity without using NAT</abbr>. Unfortunately most of the guides online use NAT for IPv4 and IPv6. NAT is necessary for IPv4, but goes against the very design of IPv6. I wanted to provide each client with a globally routable IPv6 address. This ended up being simple once I figured it out.</p>
I previous wrote a guide for setting up WireGuard to share a public static IPv4 address</a>. The formatting was ruined in the transition from my old WordPress blog to this statically generated one, but it explains how to setup a WireGuard VPN server for IPv4. This post will explain how to setup a WireGuard VPN server for IPv6.</p>

Preamble</h1>
First a major caveat. As of this writing, I've had this iteration of my VPN server running for two days. I've tested it on my home network, on my phone's cellular network, and on an IPv4 only network through my travel router. IPv6 appears to work in all cases. I haven't finished thorough testing though. There may be a number of corner cases that don't work. I will update this guide as I find and fix them. Therefore, if you find something broken, check back and I might have discovered it and posted the solution already.</p>
I also pieced my setup together by taking bits and pieces of several online guides. I pillaged from this guide</a>, this guide</a>, this guide</a>, and this guide</a>. If there are unnecessary configuration steps in this guide, I likely took it from one of these guides and didn't test my final setup without the configuration. Such mistakes are entirely my fault.</p>
In order to follow this guide, you need a source of IPv6 addresses and specifically a separate subnet from your hosting network. My ISP</abbr> provides me with a /48 prefix. This gives me roughly a bajillion addresses and subnets.</p>

Conventions Used in This Guide</h1>
For the purposes of this guide, I'm going to use the following IP addresses (`2001:db8</code> is the` `prefix reserved for examples and documentation</a> for those not aware):</p>`
`2001:db8:1234::/48</code>: The prefix provided by our ISP.</p>`
`2001:db8:1234:9999::/64</code>: The subnet of our hosting network. The subnet 9999</code> was chosen for readability purposes.</p>`
`2001:db8:1234:ffff::/64</code>: The subnet provided to our WireGuard VPN clients. Throughout this guide remember that the subnet with numbers is for our hosting network and the subnet with letters is for our VPN clients.</p>`
`2001:db8:1234:9999::1</code>: The IPv6 address used by clients to connect to our WireGuard VPN server.</p>`
`2001:db8:1234:ffff::1</code>: The IPv6 address of the WireGuard interface. This differs from the above address in that a client only uses it after it has connected to the WireGuard VPN server through the above address. Once connected, clients will use this address as their gateway.</p>`
`2001:db8:1234:ffff::1:1</code>: The IPv6 address provided to the first of our WireGuard VPN clients. This address will be incremented subsequently so our second client will have an IPv6 address of 2001:db8:1234:ffff::1:2</code>, our third 2001:db8:1234:ffff::1:3</code>, etc.</p>`
`I will also use en0</code> as the name of the network interface of our WireGuard VPN server, 51820</code> as the port used to connect to WireGuard on our server, and wg-vpn.conf</code> as the name of our WireGuard configuration file.</p>`

The Actual Guide</h1>
The first thing you will need to do is ensure that the router between your hosting network and ISP is setup to route the subnet for our VPN clients to our VPN server. How you do this will depend on both your ISP and your router. For my Ubiquiti Cloud Gateway Ultra, I created a static route that routes the entire 2001:db8:1234:ffff::/64</code> subnet to 2001:db8:1234:9999::1</code>. You will also need to configure your router's firewall to allow incoming WireGuard traffic to your VPN server.</p>
I'm hosting my VPN server on Fedora Server. By default, IPv6 forwarding isn't enabled on Fedora Server. I enabled it by adding net.ipv6.conf.all.forwarding=1</code> to /etc/sysctl.conf</code> and issued the sysctl -p</code> command to load the changes. I also added several other lines. /etc/sysctl.conf</code> on my VPN server contains the following contents:</p>

net.ipv4.ip_forward=1
</span>net.ipv6.conf.en0.proxy_ndp=1
</span>net.ipv6.conf.all.forwarding=1
</span>net.ipv6.conf.en0.accept_ra=2
</span></code></pre>
The first line enables IPv4 forwarding. It's enabled by default on Fedora Server, but I added the line just to ensure it's always enabled. The second line enables proxying NDP</abbr> packets, which is used by IPv6 to discover neighboring devices. The final line enables router advertisements while IPv6 forwarding is enabled. I added it to the file when I was trying to dole out IPv6 addresses through another method. I'm not sure if it's needed for my final setup. This is one of those potentially unnecessary configuration steps I mentioned in the preamble for this guide.</p>
The only port I opened on my VPN server's firewall is 51820</code> for UDP</abbr> packets. WireGuard only uses UDP so you don't need to open the port for TCP</abbr>. I also enabled masquerading capabilities. Masquerading capabilities are only needed for NAT, which means it's only necessary for IPv4. You don't need to enable it if you're only using IPv6 on your VPN server.</p>
Everything else happens in the WireGuard configuration file located at /etc/wireguard/wg-vpn.conf</code>. The first section of the configuration file sets up the interface:</p>
[Interface]
</span>PrivateKey = <Your Server's Private Key>
</span>Address = 2001:db8:1234:ffff::1/64
</span>SaveConfig = false
</span>ListenPort = 51820
</span></code></pre>
This is all pretty basic. PrivateKey</code> obvious contains your server's private key that was generated with wg genkey</code>. Address</code> is the IPv6 address of the WireGuard interface. Clients will use this address as their gateway once they've connected to our VPN server. SaveConfig</code> determines if the current configuration is saved when the WireGuard interface is shutdown. I generate my configuration files with Ansible so I don't want any state maintained and disable this feature. ListenPort</code> is the port through which clients will connect to the VPN server.</p>
The next section is where the heavy lifting is done. PostUp</code> commands run when the WireGuard server is being started. PostDown</code> commands run when the WireGuard server is being stopped. In this case, the PostDown</code> commands simply undo the PostUp</code> commands. Also note that %i</code> stands for the WireGuard interface name, which is wg-vpn</code> since the configuration file is wg-vpn.conf</code>.</p>
PostUp = ip6tables -A FORWARD -i en0 -o %i -j ACCEPT;
</span>PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;
</span>
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:1 dev en0
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:2 dev en0
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:3 dev en0
</span>
</span>PostDown = ip6tables -D FORWARD -i en0 -o %i -j ACCEPT;
</span>PostDown = ip6tables -D FORWARD -i %i -j ACCEPT;
</span>
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:1 dev en0
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:2 dev en0
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:3 dev en0
</span></code></pre>
PostUp = ip6tables -A FORWARD -i en0 -o %i -j ACCEPT;</code> and PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;</code> enable IPv6 forwarding between the server's network interface (en0</code> in this example) and the WireGuard interface (wg-vpn</code> in this example). This allowed IPv6 traffic originating from our clients to be forwarded out of the VPN server's network interface and return traffic routed from the VPN server's network interface to the appropriate client.</p>
PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:1 dev en0</code> and the following two lines setup NDP proxies for each client. You could probably replace all of these lines with PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::/64 dev en0</code>. Again I generate my configuration file with an Ansible playbook so it's just as easy for me to loop through my list of clients and add a line per client. As mention above, the PostDown</code> lines simply undo the PostUp</code> lines when the WireGuard interface is stopped.</p>
The final part of the file contains configuration information for each peer:</p>
[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:1/128
</span>
</span>[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:2/128
</span>
</span>[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:3/128
</span></code></pre>
This is straightforward. PublicKey</code> contains the client's public key and AllowedIPs</code> contains the IPv6 address we're assigning to the client. Running systemctl start wg-quick@wg-vpn.service</code> will bring the WireGuard interface up so clients can start connecting.</p>
The configuration file for each client is simple:</p>
[Interface]
</span>Address = 2001:db8:1234:ffff::1:1/64
</span>PrivateKey = <The Client's Private Key>
</span>
</span>[Peer]
</span>AllowedIPs = ::/0
</span>Endpoint = [2001:db8:1234:9999::1]:51820
</span>PublicKey = <Your Server's Public Key>
</span></code></pre>
Address</code> is the globally routable IPv6 address our VPN server is assigning to the client. PrivateKey</code> is the client's private key. There's similarly little to say about the [Peer]</code> section, which contains connection information for the VPN server.</p>
AllowedIPs = ::/0</code> tells the client to route all IPv6 traffic through the WireGuard interface. Endpoint</code> contains the IPv6 address clients use to connect to the VPN server. Note the square brackets. Because IPv6 addresses use ':' as a separator and ':' is also used by convention to separate an IP address from a port number, the square brackets are used to disambiguate the ':' in the IPv6 address from the ':' differentiating the port number.</p>
When the client connects to the VPN server, it will have the globally routable IPv6 address of 2001:db8:1234:ffff::1:1</code>. If you connect to a website that tests IPv6 connectivity such as this IPv4 and IPv6 connectivity test</a>, it should show 2001:db8:1234:ffff::1:1</code> as your IPv6 address.</p>
There you have it, a WireGuard VPN server that provides clients with globally routable IPv6 addresses.</p>



This Blog Is Now Available via IPv6
2025-10-17T12:00:00+00:00
Faster speeds are the only benefit I received from my recent Internet upgrade</a>. One of my biggest gripes with having to use CenturyLink when I bought this house was the complete lack of IPv6 support. Brightspeed, not surprisingly considering their incompetency, didn't add IPv6 support when they took over for CenturyLink. Lakeland Communications, however, has full IPv6 support, which means this blog is now available via IPv6.</p>
I consider this a major milestone. It's something I've wanted for many years now. I always envied people who had an IPv6 enabled Internet connection. I also hate network administrators who have an IPv6 enabled Internet connection and refuse to utilize it. Therefore, I'm going to use this occasion to rant about those network administrators and explain why their refusal is laziness at best and idiocy at worst.</p>
Even though IPv6 has been formalized by the IETF</abbr> since 1998, there remains a lot of misconceptions about the protocol. The biggest misconception is that the only major difference between IPv6 and IPv4 is that the former has a significantly larger address space. This misconception leads to some stupid objections to implementing it. The first is that IPv6 addresses can't be memorized like IPv4 addresses. Anybody who has worked with large networks knows that IPv4 address can't typically be memorized for very long either. This is why DNS</abbr> exists. You shouldn't refer to your systems by their IP addresses regardless of the version you're using. You should have a DNS server that provides memorable names to your systems.</p>
Another objection to implementing IPv6 is that it's complicated to setup. It's actually much easier to setup an IPv6 network than an IPv4 network. My home network is a good example. IPv4 interfaces don't generate their own addresses (technically they can, but those addresses aren't useful in most cases) so you need to either statically assign an address to each device or use a DHCP</abbr> server. I use DHCP to assign addresses to my devices. I operate two Kea DHCP servers configured in high availability mode for redundancy. Meanwhile, IPv6 can utilize protocols like SLAAC</a></abbr> to automatically generate their own addresses. My ISP provides me an IPv6 prefix, which my router automatically receives and advertises. Every IPv6 client can then generate an IPv6 address for itself based on that prefix. The addresses they generate are also globally routable.</p>
The last part is important. There are no more unclaimed IPv4 addresses, which makes them a scarce commodity. Not every ISP is willing to provide a static IPv4 address. Those that do typically charge a monthly fee per static IPv4 address. I rent my single static IPv4 address and have no interest in paying for more. I need to play tricks to provide all of my services via that single IPv4 address. When you connect to this blog via IPv4, several things happen. First my router uses port forwarding to connect your browser to my reverse proxy server. My reverse proxy server then uses <abbr="Server Name Indication">SNI</a></abbr> to determine where to route the connection. The connection is then proxied to the server that actually hosts this blog. This tower of redirection is necessary to host multiple websites and other servers via a single IPv4 address.</p>
There are effectively (obviously not literally) unlimited IPv6 addresses. My ISP provides me a /48 prefix. This gives me more IPv6 address than I could ever use. I could dole out 10 IPv6 addresses to every network enabled device in my house and still not make a dent in the number of addresses available to me. And all of those addresses are globally routable. This means when you connect to this blog via IPv6, you're connecting directly to the server hosting it.</p>
This fact frightens a lot of network administrators because they have this false concept that their local network is trustworthy whereas the Internet isn't. They like all of the redirection and games IPv4 requires because they believe it establishes are strong barrier between their trustworthy network and the untrustworthy Internet. Anybody who has read the news about network exploits knows this is false. Local networks aren't trustworthy. Every system you setup should be setup as if it were connected directly to the Internet. This is how I design my network.</p>
Even though my router has a firewall, every system I setup also has a firewall. Those firewalls are configured with the minimum number of open ports necessary. I also ensure SELinux is enabled on all of my systems (many network administrators disable SELinux rather than learn how to use it). I minimize the amount of unencrypted traffic on my local network. For example, my reverse proxy has a dedicated WireGuard connection to each of my servers is proxies. All traffic between it and the proxied servers goes through those WireGuard connections. The main sources of unencrypted traffic are my DHCP servers and that's because DHCP can't be secured. My networking equipment does use DHCP Guard to ensure only my DHCP servers can provide leases through. IPv6 eliminates the need for those WireGuard connections by eliminating the need for the reverse proxy. It also eliminates the need for DHCP since devices can configure their own IPv6 addresses.</p>
I've heard a few network administrators complain that providing websites via IPv4 and IPv6 complicates setting up TLS. This might have been the case when getting signed certificates was largely a manual task, but it's no longer the case now that getting signed certificates is largely automated. I've automated the task of getting signed certificates ever since Let's Encrypt's signing certificate was added to every major browser. Originally I did this via certbot, but now that I use Caddy</a>, my HTTPS servers do it automatically (a few of my servers like my e-mail server still use certbot). Certbot and Caddy both operate perfectly well via IPv6. In fact this blog is secured by separate TLS certificates depending on if you connect via IPv4 or IPv6. If you connect via IPv4, you use the certificate obtained by Caddy on my reverse proxy. If you connect via IPv6, you use the certificate obtained by Caddy on the server hosting my blog.</p>
I'll end my rant here since this post is getting longer than I anticipated. In summary, IPv6 is better than IPv4 in every way. Every objection to implementing IPv6 is dumb. Network administrators who have the option to implement IPv6 but don't are wrong.</p>