OpenVPN v2.2 does not contain the patch for OpenVPN itself, but it has the necessary patches for the Windows TAP driver, and the v2.2.2 package contains a signed tap driver that can be used on Win7-64 to make things work.
OpenVPN v2.3 will have both patch sets incorporated to provide a fully IPv6 capable OpenVPN. We expect the first alpha release of v2.3 to happen at FOSDEM2012 in February 2012 (but if you're impatient, get the sources from openvpn git).
Every client is assigned a single IPv6 address by the server, coming from a shared transfer network between all clients and the server. Usually this would be a common /64, but theoretically a smaller subnet could also be used (not implemented yet).
This is analogous to the IPv4 option ``--topology subnet'', implemented by OpenVPN 2.1 and up, and unlike the old ``net30'' topology that allocates a dedicated /30 per client. Since IPv6 subnets are ``big enough'' by definition, the extra effort of defining different topology options and writing the implementation could be avoided. (Depending on operating system capabilites and configured IPv4 topology, the actual tunnel interface will be configured as ``point-to-point'' or ``network'', but logically it's always a shared subnet for all clients).
If a whole subnet is to be routed to a network ``behind'' an OpenVPN client (in addition to the single host address allocated automatically), this can be done with ``iroute'' and per-client configuration (--client-config-dir dir).
No automatic support for ``receive a whole prefix from the server, do something smart with it'' (as in ``configure on internal ethernet, setup radvd, ...'') exists in the client implementation yet. If needed, this could be achieved by scripts on the client side in combination with something like ``push setenv-safe MYNETWORK 2001:db8:1::/64'' (see man page) in the server's per-client configuration.
option | what it does |
---|---|
server-ipv6 2001:db8::/64 | sort of a macro - enables IPv6 server mode, sets up local IPv6 addresses for the TUN interface on the server (ifconfig-ipv6 $prefix::1 $prefix::2), sets up ifconfig-ipv6-pool and tun-ipv6 accordingly |
ifconfig-ipv6 2001:db8:5::1 2001:db8:5::2 | interface configuration for TUN interface, usually setup
automatically via ``server-ipv6'' on the server side and via
automatic push from the server to the client. The first address given is used for the ``tun'' interface (``ifconfig'' on the operating system side), the second address is used as a route gateway for operating systems that do not know how to setup a route to an interface without an explicit gateway IP address. |
ifconfig-ipv6-pool 2001:db8:6::7/64 | hand out IPv6 addresses from the specified pool with the specified netbits (/64) to the clients. Do not use IPv6 addresses lower than the one specified (in this example: ::1 to ::6 are reserved for other purposes). Usually setup
automatically by ``server-ipv6''. caveat: the implementation is currently tied to ``ifconfig-pool'' - that is, IPv6 addresses are always allocated and released together with IPv4, and if the IPv4 pool is full, no IPv6 address can be allocated either. Needs cleanup when IPv4 is finally dead. |
ifconfig-pool-persist file sec | not a new option, but now also used to store ``ifconfig-ipv6-pool'' assignments (for information, not used on reading) |
iroute-ipv6 2001:db8:a0::/60 | route an IPv6 prefix to a specific client (goes to per-client configuration file, needs ``route-ipv6'' statement to install the route from the OS to the OpenVPN server) |
route-ipv6 2001:db8:1000::/60 | similar to ``route'' for IPv4 - route this prefix from the operating system to the OpenVPN process, and subsequently across the tunnel. Needed to complement ``iroute-ipv6'' on the server side, and pushed to the client to get packets to the ``internal network'' routed through the tunnel. |
push route-ipv6 ... | tell the client to route the specific prefix via the OpenVPN tunnel |
ifconfig-ipv6-push 2001:db8:1001::1 | Push ``ifconfig-ipv6'' config to client, and route the specified IPv6 address to that client. To be used from ccd/ per-client configuration, analogous to ``ifconfig-push'' for IPv4. |
tun-ipv6 | enable IPv6 routing on the tunnel. Not strictly a new option, but was only implemented in point-to-point mode so far (with manual configuration of all the IPv6 parameters and routing). |
OS/variant | server-ipv6 | client-ipv6 | remarks |
---|---|---|---|
Linux/iproute2 | ok, 09-12-31 | ok, 09-12-31 (*) | gert |
Linux/ifconfig | ok, 09-12-31 | ok, 09-12-31 | gert, berniv6 |
Linux/ARM (Debian Squeeze) | ok, 10-06-18 (*) | ok, 10-06-18 | gert |
FreeBSD 6.3/i386 | ok, 10-01-01 (*) | gert | |
FreeBSD 7.3/i386 | ok, 10-09-01 (*) | gert | |
MacOS X 10.5 i386 | ok, 10-01-02 | gert | |
NetBSD 3.1/Sparc64 | no kernel IPv6 support on tun interfaces | gert | |
NetBSD 5.0/Sparc64 | ok, 10-01-03 | gert | |
Solaris 10U5/Sparc64 | ok, 10-01-04 | gert | |
Windows XP | ok, 10-03-07 | gert (tap 9.7!) | |
Windows 7 Home Premium | ok, 11-05-20 | gert (signed tap from 2.2 release) | |
OpenWRT 10.03/ar71xx | ok, 10-06-10 (*) | ok, 10-06-18 | gert (ipk here) |
OpenBSD 4.7/i386 | ok, 10-08-08 | gert (in git) |
Other combinations that have been (mostly successfully) tested:
Client | Server | remarks |
---|---|---|
unmodified 2.1rc15 | IPv6-enabled server | warnings about unknown config options (ifconfig-ipv6, route-ipv6), but does not fail |
unmodified, various client versions | IPv6-enabled server | warnings about unknown config options (ifconfig-ipv6, route-ipv6), but does not fail |
unmodified, various client versions | patched server, but IPv6 not enabled | no visible change to the client - works as usual |
older clients (debian lenny, 2.0rc11) | IPv6-enabled server with lots of ``push'' options configured (long string, needing push-continuation) | fails, because IPv4 ifconfig is sent in a 2nd ``push'' packet, which the older client doesn't handle (reduce number of ``push'' options) |
Tests needed...:
Date | Link | ChangeLog |
---|---|---|
20009-12-31 | openvpn-2.1-ipv6-20091231-1.patch.gz | basic client-server p2mp functionality works tested on linux with a single simultaneous client (ping, and ssh). iroute-ipv6 is not working yet. |
2010-01-01 | openvpn-2.1-ipv6-20100101-1.patch.gz | iroute-ipv6 implemented and tested (Linux and FreeBSD 6), works. tested on FreeBSD 6.3 (server side), works. tested on NetBSD, does not work yet. ChangeLog.IPv6 and README.IPv6 included. |
2010-01-03 | openvpn-2.1-ipv6-20100103-1.patch.gz | fixed system-dependent stuff for NetBSD and MacOS X (major rework of
tunnel open/read/write code for NetBSD, needs to use multi-af mode). fixed setting of gateway IPv6 address for route-ipv6 config options without gateway address. tested on MacOS 10.5 (client side). works. tested on NetBSD 5.0/Sparc64 (client side). works!. |
2010-01-04 | openvpn-2.1-ipv6-20100104-1.patch.gz | adapted ifconfig/route stuff and system dependent stuff (u_int32_t)
for Solaris 10. tested on Solaris 10/Sparc64 (client side) - works!. Use together with the ``new'' tun/tap driver from here. Implement online help (openvpn --help) for new options. |
2010-01-14 | openvpn-2.1-ipv6-20100114-1.patch.gz | fixed NetBSD-pre-4.0 which has no multi-af tunnels. implement ``ifconfig-ipv6-push'' ccd/ option (for gizmo). add lots of warnings to code to spot common misconfigurations. GIT repository set up (berniv6). |
2010-02-16 | openvpn-2.1-ipv6-20100216-1.patch.gz | print patch version on --version. fix ``make check'' regression (revert unneeded change). rebase to OpenVPN-Testing GIT tree. |
2010-03-07 | openvpn-2.1-ipv6-20100307-1.patch.gz | Windows support! (needs new TUN/TAP driver, no easy-to-install binary
distribution yet) cleanup MacOS X support (clean deconfiguration of IPv6 address on close) cleanup NetBSD support (destroy/recreate tun, remove ``old'' config) |
2011-04-24 | openvpn-2.2RC2-ipv6-20110424-2.patch.gz | patch vs OpenVPN 2.2 RC2 Solaris TUN and TAP support OpenBSD support (tested on OpenBSD 4.7) Linux/iproute2 and "topology subnet" + ipv6 fixed various platform cleanups Linux and Solaris: configuring and pushing IPv6 addresses for "TAP" interfaces implemented. Pushing routes doesn't work yet. |
2011-05-22 | openvpn-2.2.0-ipv6-20110522-1.patch.gz | patch vs. OpenVPN 2.2.0 release Windows IPv6 cleanups (properly deconfigure addresses and routes on disconnected). Windows installer is here, tested on XP SP3 and Win7. This patch does not compile with Microsoft Visual C++ on Windows, but it nicely builds with msys/mingw, read and follow ``domake-win'' in the source. |
A (preliminary) Windows package of openvpn-testing/allmerged ("with all the nice goodies") as of September 08, 2010, with the openvpn-gui snapshot 20100827, is HERE
If you use OpenWRT, I have compiled two packages (OpenVPN 2.1.1 plus my
IPv6 patch, no other -devel patches) for the platforms I have available
and can test. Download with "wget" to your router, install with "opkg install ./openvpn*ipv6*ipk"
UPDATE: there is an openvpn-devel package available in the official openwrt packages feed now, so you can get your IPv6-enabled binary from THERE (pick the subdirectory according to platform, and then go to the "packages" directoryn in there, e.g. ".../trunk/ar71xx/packages/") and the OpenWRT 10.03.1 release should then have it available for direct installing with "ipk install openvpn-devel".
Whether you trust a binary compiled by someone you don't know is your choice, of course. If you don't, just get the OpenVPN source and the patch set, review the source for backdoors, and build your own binary.
git://git.birkenwald.de/openvpn.gitand my stuff is in the ``gert-ipv6'' branch.
There is an official OpenVPN testing repository now, to be found at:
git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.gitThe IPv6 payload and IPv6 transport patch have both been merged into the ``master'' branch. The old ``feat_ipv6_payload'' branch is not maintained anymore, work continues in ``master'', which will be released as v2.3 alpha really soon now.
You can also comment my blog article (German!) about this project.
Please do not send me questions for precompiled binaries for your architecture of choice. This stuff is in a quite early phase, and you should have some experience in compiling and patching open source software to make use of it (I hope that the IPv6 stuff will be integrated into the main OpenVPN line, and then the distribution vendors will of course pick it up).