Opened 11 years ago

Closed 3 years ago

#208 closed Feature Wish (fixed)

Allow ipv6 only tunnels

Reported by: joshie Owned by: Gert Döring
Priority: major Milestone: release 2.5
Component: Configuration Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: ipv6


It would appear as of 2.3-alpha1, in order to have an ipv6-tun, you must use the server directive, which forces ipv4 as well. It is preferable to those who wish to only have an ipv6 tunnel not to be forced to have an additional ipv4 tunnel.

Change History (16)

comment:1 Changed 11 years ago by David Sommerseth

Keywords: ipv6 added
Owner: set to Gert Döring
Status: newassigned
Version: git master branch

comment:2 Changed 11 years ago by Gert Döring

Milestone: release 2.4

Currently, the OpenVPN implementation assumes "always IPv4, optional IPv6". So you need to have IPv4 on your tunnel. (It's not "an additional tunnel" but the tunnel will be dual-stacked).

If you want to have it IPv6-only, just configure some RFC1918 IPv4, and do not route
that anywhere - it's not pretty, but it will not have any extra overhead except send a few bytes of "ifconfig for IPv4" at session handshake.

To make IPv4 optional is a useful goal, but first we need to get 2.3 released :-)

comment:3 Changed 10 years ago by darx


comment:4 Changed 9 years ago by Samuli Seppänen

Priority: majorminor

comment:5 Changed 8 years ago by WGH

but it will not have any extra overhead except send a few bytes of "ifconfig for IPv4" at session handshake.

Even if you don't actively use the IPv4 network, it still will be "attached" to your computer. It might prevent you from using several VPNs simultaneously, or it might even conflict with some other intranet.

comment:6 Changed 6 years ago by Gert Döring

Milestone: release 2.4release 2.5

Nobody had time to work on this for 2.4 - but for 2.5 we really should be able to do ipv6-only. Bumping milestone.

comment:7 Changed 5 years ago by Antonio Quartulli

@gert it seems people are asking for this feature more and more.
Since you have the best understanding of the ipv6 infrastructure in openvpn, would you mind providing a list of things "to check" and "to hack" in order to get done with this? (I am not sure how easy this is)

By having a list of smaller tasks we might be able to coordinate the effort of different people and finally move forward.

comment:8 Changed 5 years ago by Gert Döring

Uh... let me try...

  • client-side is fairly easy
    • change the ifconfig setup stuff in tun.c to do IPv6 even if IPv4 has not been set up (as far as I remember, ifconfig is only run if IPv4 is requested, and later in that same function, we check for "oh, do we want IPv6 as well?")
    • test across all platforms if IPv6-only tuns work nicely
    • test this on 3 as well - ISTR that iOS was a bit icky if you give it a v6-only tunnel, but this might have been fixed now
    • this can be tested fairly easy independently from the server side by using --pull-filter ignore "ifconfig " in the client config - pretending "there is no IPv4 in the PUSH_REPLY"
  • server side stuff is more interesting
    • maybe trivial: --server-ipv6 depends on --server being active - so this needs to be de-coupled, or specifically, --server-ipv6 needs to enable the "I am a p2mp server!" functionality without the "IPv4 bits"
    • decouple IPv6 pool handling from IPv4 - if we have no IPv4, we have no IPv4 pool, and the naive logic "just take the offset from the IPv4 pool and add it to the IPv6 base address" will no longer work (--ifconfig-ipv6-push might still work)
    • check all the connection setup bits if there is anything relying on "we do have an IPv4 address for the incoming client" - I could see push.c, multi.c as possible candidates for surprises
      • using --push-remove 'ifconfig ' might be enough to bring up fireworks in push.c, though the rest of the code will still assume "client instance has v4" so it's not a full-grown test
    • the actual forwarding parts should be fine, the mroute stuff only cares for a single mroute, and never checks for "other" routes being present

comment:9 Changed 5 years ago by Gert Döring

Actually this seems to be a nice goal for 2.5 - v6-only tunnels.

The client side should be trivial enough that we might even backport to 2.4, but the server is larger changes (pool). As usual, if you want a server with all the cool things in it, you need to run the latest version.

comment:10 Changed 5 years ago by tct


comment:11 Changed 5 years ago by Gert Döring

First patch set has landed and discussion has started...

comment:12 Changed 4 years ago by Antonio Quartulli

Update: the patches implementing the client side of things have been merged. We now miss some changes required by the server side (i.e. handling pool, decoupling v4/v6 logic) and small fixes for the redirect-gateway logic.

comment:13 Changed 4 years ago by Antonio Quartulli

Priority: minormajor

moving to 'major' as we agreed this is a "nice to have" in 2.5

comment:14 Changed 3 years ago by Gert Döring


Thanks to Antonio's hard work and limitless patience for my endless complaints, we have done most of the heavy lifting. This can now be tested (I found a number of constellations already that caused hickups, but I'm sure I'm not half as creative as our users).

A few things remain to be fixed - noting here so they do not get lost

  • 6/7 "redirect ipv4 gateway" if we have no IPv4 in the tunnel - the v4 patch breaks "redirect-private" which is not good.
  • 7/7 "lift restrictions on pool size" - this changes the start of the pool (0x1000 to +2), which will change existing behaviour for "large" pools (/64.../111) without obvious benefit. Need to come to an agreement here what is "best".
  • MULTI: no --ifconfig-pool netmask parameter is available to push to ... warning when using v6-only pools - the code here works "sort of accidentially", but maybe it should explicitly check for pool->ipv4.enabled and skip all the tun/tap/topology/... crap.
  • the "cap pool size" math is not working right for sufficiently poorly specified pools
  • pool.h grew an extra #include "options.h" which should be cleaned up while at it
  • test with OpenVPN 3 client
Last edited 3 years ago by Gert Döring (previous) (diff)

comment:15 Changed 3 years ago by Gert Döring

6/7 + 7/7 have been merged

a bit of cleanup is still needed (uncrustify & options.h on pool.c, multi.c warning)

pool size math needs fixing for sufficiently funky pool specifications.

But this is minor - the main thing is *IN*. Thanks!

comment:16 Changed 3 years ago by Gert Döring

Resolution: fixed
Status: assignedclosed

12:55 <@ordex:#openvpn-devel> cron2: you may have the honor to close it !

so. closing it, though ordex really did most of the coding :-)

(And it was like I expected - not much effort codewise, but very much effort figuring out how to disentangle the bits...)

"pool size math for funny pools /64../111" is still open, but I'll tackle this outside of #208

Note: See TracTickets for help on using tickets.