Table of Contents
IPv6 in OpenVPN
This page describes IPv6 support in OpenVPN.
Starting officially in the 2.3.0 release, OpenVPN supports IPv6 inside the tunnel, and can optionally be configured with IPv6 as a transport protocol for the tunneled data. There were some unofficial developer patches for the 2.2.x series that added partial IPv6 support (Debian in particular chose to integrate these patches into some of their builds.)
Providing IPv6 inside the tunnel
This section walks through providing IPv6 connectivity inside the tunnel; this will discuss a routed setup; a bridged (dev tap) setup is not recommended in general, and users doing so are presumably advanced enough to know what they're doing.
A few things must be met in order to use IPv6:
- An existing and functional OpenVPN configuration (use the official howto if you don't yet have this.)
- Both client and server must support IPv6; most modern systems these-days include this support already
- Recommended A routed IPv6 network block that will reach the host configured as the OpenVPN server
- alternatively, check section "Splitting a single routable IPv6 netblock" below
Details: IPv6 routed block
In a routed setup, you cannot use your on-link network; you must use a unique routed network range, just like when routing with IPv4. Most ISPs should have a facility to obtain a routed block on request, or sometimes provided as part of DHCPv6-PD; these concepts are outside the scope of this document. Speak to your ISP or use other IPv6 learning resources for further information.
It is recommended to use a /64 for your OpenVPN subnet. While OpenVPN can happily use smaller networks (such as a /112) this is not compatible with the 2.2.x dev-patches that f.ex Debian uses. Thus a /64 is the preferred choice for an OpenVPN IPv6 allocation.
In this document, we'll assume you have the following from the OpenVPN server's viewpoint:
- The OpenVPN server has an IPv6 IP of 2001:db8:abc::100/64 on its LAN interface
- The following block is routed to the OpenVPN server host: 2001:db8:123::/64
Additional OpenVPN config
There are 2 ways to add IPv6 addressing and pool options to the server, similar to what OpenVPN supports for IPv4: using a helper-directive, and by expanding the helper-directive. The expansion is required if you do not wish to use the automatic values the helper-directive supplies. Clients who use --client or --pull will get the tun-ipv6 directive and addressing from the pool pushed as a result.
Config stanza using the helper
Add the following to a functioning OpenVPN config:
Config stanza with expanded directives
Add the following to a functioning OpenVPN config:
tun-ipv6 push tun-ipv6 ifconfig-ipv6 2001:db8:123::1/64 2001:db8:123::0/64 ifconfig-ipv6-pool 2001:db8:123::101/64
Note by PaulM: the above results in openvpn complaining that ifconfig-ipv6 contains invalid addresses - the netmasks are not needed/wanted, so this is what you have to use:
tun-ipv6 push tun-ipv6 ifconfig-ipv6 2001:db8:123::1 2001:db8:123::2 ifconfig-ipv6-pool 2001:db8:123::8000/64
Pushing IPv6 routes
Pushing routes over the tunnel works much like it does in IPv4, but you use --push "route-ipv6 NETWORK/CIDR"
Using the addressing examples shown above, if you wanted to expose the server-side network of 2001:db8:abc::/64, you could use:
push "route-ipv6 2001:db8:abc::/64"
To redirect all Internet-bound traffic, use the current allocated public IP space like this:
push "route-ipv6 2000::/3"
Splitting a single routable IPv6 netblock
Otherwise, there is a way out. Typically /64 IPv6 netblocks are assigned, leaving a large address space. For an OpenVPN setup, this address space can be broken in 2, /65-prefix parts, the first being assigned to the physical network interface, and the second to the VPN. Warning operating netblocks smaller than /64 might break some network features.
Avoid this setup if you are using any of:
- SLAAC. If you are using SLAAC and have no way around, ask your ISP for permission to use static address assignment on your VPN server.
- IPv6 Multicast - RFC3306
- Cryptographically Generated Address - CGA - RFC3972
- NAT64 - RFC6052
- IPv6-to-IPv6 Network Prefix Translation - NPTv6 - RFC6296
- Identifier-Locator Network Protocol - ILNP - RFC6741
- Multihoming Shim Protocol for IPv6 - shim6 - RFC5533
See this Internet Draft for details.
Split netblock configuration
Get the original IPv6 netblock on your OpenVPN server; let's assume it's
- check that your NIC uses no addresses in the upper /65 block (in this case, addresses greater than 2001:db8:123:8000::/65). If you do, you can't use this setup until you eliminate those.
- re-assign the new restricted netblock – lower part. The command for this depends on your OS. For example, in FreeBSD:
### check this on your OS! # ifconfig igb0 inet6 2001:db8:123::/64 -alias # ifconfig igb0 inet6 2001:db8:123::/65 ### ### re-assign the other aliases previously set under the /64 block # ifconfig igb0 inet6 2001:db8:123::dead/128 alias # ifconfig igb0 inet6 2001:db8:123::ea:beef/128 alias # ...
- assign the higher part of the restricted netblock to OpenVPN. Add
# add this line server-ipv6 2001:db8:123:8000::/65
- restart the VPN
You can do this also if your assigned IPv6 netblock is already shorter than /64, e.g. /112 . Just perform the same steps and compute the base address of the upper subnet: the lower starts with the last bit in the netmask set to 0, the upper starts with it set to 1.
If you are running Android 4.4.x you will encounter a bug related to the tun0 interface.
After setting up the OpenVPN connection you are able to ping6 the Android 4.4.x device from your server, but you cannot ping6 the server or other IPv6 targets from your Android 4.4 device. This bug doesn't occur in Android 4.3 (And earlier?) and occurs in all Android 4.4.x versions including 4.4.2. There is no known workaround for this issue except hoping on a fix in Android 4.4.3.