The way a VPN works is quite simple, a client connects to a server, a ciphered tunnel is created between the client and the server. And as soon as this tunnel is up and running, the client and the server start to exchange their network traffic trough that tunnel. There are many possible applications to create with a such tool, this article focus on the following(s):
- Exchanging both IPv4 and IPv6 traffic trough the VPN tunnel
Table of contents
- A working Debian-based server
- The Debian server has IPv4 enabled and fully working
- The Debian server has IPv6 enabled and fully working
- The Debian server only has a /128 IPv6 prefix
- UFW is installed and configured on the Debian server
- An installed and working OpenVPN server >= 2.4.0 (latest 2.4.x stable is recommended)
- The OpenVPN server must be reachable throw IPv4, IPv6, or both
- The OpenVPN server is already able to exchange IPv4 traffic through the tunnel
A few words about the server
It is not a normal situation to have a server with only a /128 IPv6 prefix. The standard is supposed to be a /64 prefix. That kind of situation occurred to me because I picked a very cheap VPS provider. And the delivered VPS came along with a single IPv4 address but also a single IPv6 address. If you are familiar with IPv6, you may know that it breaks few mechanisms. I could only suggest you to pick a server with a /64 prefix, a smaller prefix (e.g /56), or a server able to join a DHCP-PD server. If you managed to get that, parts of the current article are completely worthless, and the official OpenVPN documentation about IPv6 should be enough to configure your server.
To be honest, I didn’t notice the /128 IPv6 address at first, and I didn’t really care. It becomes an enjoyable challenge to configure an OpenVPN server in such environment.
The configuration describes through this article would also work even if you have a /64 or a smaller prefix defined on the server side. But I strongly suggest you to avoid NAT66 if you can’t.
Enabling the server to carry IPv6 through the tunnel
It is nearly similar than enabling IPv4 NAT. First you have to pick an ULA /64 prefix, E.G.
fd42:feed:feed:feed::/64. You can pick that one if you want, even if you need to carry internet traffic. It will have the same purpose than an IPv4 private network like
Forwarding must be enabled on the server, to do so, set the following parameter value to 1 in the file
net.ipv6.conf.all.forwarding = 1
then apply the change
firstname.lastname@example.org:~# sudo sysctl -p
Once IPv6 forwarding is enabled, update the ufw configuration to enable NAT for IPv6. The following lines must be added into the file
# START OPENVPN RULES # NAT table rules *nat :POSTROUTING ACCEPT [0:0] # Allow traffic from OpenVPN client to eth0 -A POSTROUTING -s fd42:feed:feed:feed::/64 -o eth0 -j MASQUERADE COMMIT # END OPENVPN RULES
ATTENTION: Do not forget to replace the ULA /64 prefix you have picked and also the interface name that will act as NAT outside interface on your server. The NAT outside interface should be the interface connected to internet.
Then restart the ufw service:
email@example.com:~# sudo ufw disable firstname.lastname@example.org:~# sudo ufw enable
Now update the OpenVPN server configuration file
# ULA IPv6 network that will be used on the tunnel interfaces # <!> MANDATORY <!> server-ipv6 fd42:feed:feed:feed::/64 # push routing directives on the client side # <!> MANDATORY <!> push "redirect-gateway ipv6 bypass-dhcp" # push IPv6 OpenDNS servers on the client side # it could be any public dns of your choice # <!> OPTIONAL <!> push "dhcp-option DNS6 2620:0:ccd::2" push "dhcp-option DNS6 2620:0:ccc::2"
Then restart the OpenVPN server to apply the configuration updates.
email@example.com:~# sudo systemctl restart openvpn@server
And it is done, the VPN clients and the server can now exchange IPv6 traffic through the ciphered tunnel.
With the NAT66 configured on the server side, it is now possible to forward part or all of the client IPv6 traffic through the VPN tunnel.
For obvious security reasons, the following files are not provided: ca.crt, crl.pem, dh.pem, server.crt, server.key, ta.key
Understanding IPv6 routing policy