Enable IPv6 on tunnel interface

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable IPv6 on default network device
2. Configure OpenVPN to act as a bridge (tap)
3. Start VPN tunnel (set new default route)

What is the expected output? What do you see instead?
Only IPv4 traffic is being routed through the VPN tunnel. IPv6 is disabled
on the TUN/TAP device. But as it is still enabled on the physical device,
IPv6 traffic is being routed directly. If I enable IPv6 manually, IPv6
traffic is being routed through the tunnel:

sysctl -w net.inet6.ip6.accept_rtadv=1
ip6 -d en[0-9]
ip6 -u $DEVICE
rtsol $DEVICE

What version of Tunnelblick are you using? On what version of OS X? PPC or
Intel?
Tunnelblick 3.0b18, OS X 10.6.1, Intel.

Please provide any additional information below.
As OpenVPN does not support route handling for IPv6, it would be nice if
Tunnelblick could do the workaround here. The commands listed above disable
IPv6 on all network interfaces and enable it on the TUN/TAP device. On
connection close, the previous state should be re-established.

Original issue reported on code.google.com by dbert...@gmail.com on 6 Oct 2009 at 3:12

[GoogleCodeExporter]

I'm attempting to use Tunnelblick+OSX to get an ipv6 connection from one of my 
servers. I'm using an up-script like:

#!/bin/sh
/sbin/ifconfig $dev inet6 $laptop-v6
/sbin/route add -inet6 default $server-tap-v6
/sbin/route add -inet6 2000:: -prefixlen 3 $server-tap-v6

this _works_, but I'm having reliability problems, which I think is an OSX 
routing table issue. if I turn my VPN on and off several times, I lose my ipv6 
connection. I've tried using a custom down-script to clean up after myself, but 
I still wind up with multiple fe80::$blah%tap0 entries (once tap0 is gone, they 
rename to %en0). again, I think this is an OSX issue or a flaw with my script 
setup, but might as well ask the experts, right?

Original comment by roger.bu...@gmail.com on 7 Nov 2010 at 1:58

[GoogleCodeExporter]

If you haven 't already seen them, you might want to take a look at two 
discussions:

http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/7dedce9f
3ebc4002

and

http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/c377f551
3fb04686

Original comment by jkbull...@gmail.com on 7 Nov 2010 at 2:07

[GoogleCodeExporter]

The solution described in the discussion is actually exactly what I'm doing. 
But right now, this is the reason to have custom up and down scripts. Would be 
nice to have an additional config option "Enable IPv6 on TUN/TAP device" which 
will execute something like this in the default scripts:

if ${ARG_IPv6} ; then
    ip6 -d ${NET_DEV}
    ip6 -u ${VPN_DEV}
    sysctl -w net.inet6.ip6.accept_rtadv=1 
fi

In my case, this would be sufficient to get a working default route by route 
advertisment.

Original comment by dbert...@gmail.com on 14 Dec 2010 at 9:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Comment 4 by pablotha...@gmail.com has been deleted. It was a duplicate post.

Original comment by jkbull...@gmail.com on 9 Feb 2011 at 11:32

[GoogleCodeExporter]

The solution for this is to add 

ipconfig set "$dev" AUTOMATIC-V6

to client.up.tunnelblick.sh:960 (add it right after the existing ipconfig 
command)

Original comment by kc9...@gmail.com on 5 Aug 2012 at 8:39

[GoogleCodeExporter]

kc9jud, thanks for your comment.

I am not knowledgable enough about this to know if this is the right approach.

I can see that it will only work on TAP connections, which is probably your 
intention, but what would be needed to make IPv6 work on TUN connections, too?

And what about DNS? Right now, from what I can tell, the up/down scripts deal 
only with IPv4 (because the up script gets the "PrimaryService" UUID from 
"State:/Network/Global/IPv4" in the system configuration). There doesn't seem 
to be a corresponding "State:/Network/Global/IPv6" entry (in a Lion system with 
IPv6 configured automatically, anyway). So do we just use the "IPv4" entry? Are 
there any circumstances under which an "IPv6" entry shows up (maybe if IPv4 is 
disabled somehow)? Can nameserver addresses be IPv6 addresses?

As you can see, I have many questions. I'd like to add IPv6 support to the 
standard up/down script, but don't want to mess things up. (Mountain Lion 
showed the fragility of Tunnelblick's way of modifying DNS settings, as did 
Leopard -- for both OSs it took a lot of effort to get Tunnelblick working 
properly. (And I'm not sure it _is_ working properly yet on Mountain Lion.)

In any case, your comment will help others who make their own scripts or modify 
the standard scripts., so thanks!

================

To clarify (because different revisions of the up file have different line 
numbers), here is some context to show where in client.up.tunnelblick.sh file 
the line should go: 

 if ${ARG_TAP} ; then
    # Still need to do: Look for route-gateway dhcp (TAP isn't always DHCP)
    bRouteGatewayIsDhcp="false"
    if [ -z "${route_vpn_gateway}" -o "$route_vpn_gateway" == "dhcp" -o "$route_vpn_gateway" == "DHCP" ]; then
        bRouteGatewayIsDhcp="true"
    fi

    if [ "$bRouteGatewayIsDhcp" == "true" ]; then
        if [ -z "$dev" ]; then
            logMessage "Cannot configure TAP interface for DHCP without \$dev being defined. Exiting."
            exit 1
        fi

        ipconfig set "$dev" DHCP

+       ipconfig set "$dev" AUTOMATIC-V6
+
        configureDhcpDns &
    elif [ "$foreign_option_1" == "" ]; then
        logMessage "No network configuration changes need to be made."
        if ${ARG_MONITOR_NETWORK_CONFIGURATION} ; then
            logMessage "Will NOT monitor for other network configuration changes."
        fi
    else
        configureOpenVpnDns
        EXIT_CODE=$?
    fi

Original comment by jkbull...@gmail.com on 5 Aug 2012 at 9:05

[GoogleCodeExporter]

I can verify that my "fix" works for bridged TAP interfaces, which, for what 
it's worth, is what the OP asked. 

As for running over TUN interfaces, I think that's an issue which has to be 
addressed in OpenVPN. If I understand how TUN interfaces work, the IP 
address/routing/DNS all gets handled "out-of-band" -- that is, OpenVPN handles 
them before the interface starts passing packets. If that's so, then OpenVPN 
needs to know how to route packets and hand out IP addresses. 

If someone with a better understanding cares to explain it better, it would be 
much appreciated. :-)

Original comment by kc9...@gmail.com on 6 Aug 2012 at 12:49

[GoogleCodeExporter]

As for DNS, I can see that State:/Network/Global/IPv6 appears:

...
  subKey [50] = State:/Network/Connectivity
  subKey [51] = State:/Network/Global/DNS
  subKey [52] = State:/Network/Global/IPv4
  subKey [53] = State:/Network/Global/IPv6
  subKey [54] = State:/Network/Global/Proxies
  subKey [55] = State:/Network/Interface
...

However, I need to get my DHCPv6 server up to test and see if DNS gets handled 
automagically.

Original comment by kc9...@gmail.com on 6 Aug 2012 at 12:56

[GoogleCodeExporter]

OpenVPN itself doesn't really do anything with DNS other than aggregate DNS 
info such as servers, domain, etc., from the config file, command-line options, 
and "pushed" data from the VPN server, and pass that info on to the up script 
(supplied by Tunnelblick). The up script then figures out what to do, based on 
the computer's specific network configuration, integrating what OpenVPN says it 
want with any manual settings on the computer and any DHCP-supplied settings, 
then figures out how to make it happen.

And the proposed patch does nothing if the TAP interface isn't set up as a DHCP 
interface. (Please don't take that as a criticism; I know that's what you 
designed it to do. I'm just saying that the patch doesn't handle all 
situations. And although you may have tested it on your particular setup, there 
are a lot of different configurations that will need to be considered.

Mostly I'm just trying to say it is more complicated than you think. It's great 
that you have it working for yourself and thank you for sharing your patch for 
others to try out and use, but I don't think it's ready to be put in 
Tunnelblick with a claim that it "adds IPv6 support" or some such claim. Not 
that you've claimed that -- I just mean that's what I want to be able to say -- 
"IPv6 works" -- without a bunch of qualifiers. Since Lion and Mountain Lion and 
OpenVPN 2.3 all "work" with IPv6 (whatever that means), support.

Again, thanks for your contributions.

Original comment by jkbull...@gmail.com on 6 Aug 2012 at 2:35

[GoogleCodeExporter]

Agreed -- I spoke too broadly. My piece is exactly that -- only a piece of the 
total implementation. In fact, it only seems to do SLAAC -- I am beginning to 
suspect that stateful DHCPv6 does not get enabled this way (I can't confirm 
that if pressed -- still troubleshooting). Since most* of the time Router 
Advertisements do not include DNS information, this doesn't at all address DNS. 
My question is, do IPv6 DNS servers have to be treated differently from IPv4 
DNS servers? From my understanding, the transport protocol (IPv4 vs. IPv6) is 
independent of the records served (A vs. AAAA) -- can't IPv6 addresses just be 
added to the system DNS configuration right beside IPv4 addresses? That's what 
happens when I connect to my dual-stack network natively. There don't seem to 
be separate settings for IPv4 DNS and IPv6 DNS.

A different question is whether or not OpenVPN can hand out IPv6 addresses and 
routes for TUN devices -- that seems to be a separate step from setting up DNS.

Again, I apologize for speaking too rashly -- I was so excited to even get IPv6 
connectivity over my TAP device that I just *had* to share! Haha

*with the exception of RFC 6106

Original comment by kc9...@gmail.com on 6 Aug 2012 at 4:35

[GoogleCodeExporter]

No need to apologize -- every piece of the puzzle here helps!

Original comment by jkbull...@gmail.com on 6 Aug 2012 at 9:57

[GoogleCodeExporter]

Alright, I got some more time to work on this. I can verify:

1) When I connect to a network with IPv6 over a TAP tunnel, I can see that the 
following keys in scutil are being created:
...
  subKey [82] = State:/Network/Service/AUTOMATIC-V6-tap0/DNS
  subKey [83] = State:/Network/Service/AUTOMATIC-V6-tap0/IPv6
...
  subKey [87] = State:/Network/Service/DHCP-tap0/DHCP
  subKey [88] = State:/Network/Service/DHCP-tap0/DNS
  subKey [89] = State:/Network/Service/DHCP-tap0/IPv4
...

These keys get created with both RFC6106-style RAs as well as DHCPv6.

2) The contents of State:/Network/Service/AUTOMATIC-V6-tap0/DNS are as follows:

<dictionary> {
  ServerAddresses : <array> {
    0 : 2001:470:20::2
    1 : 2001:4860:4860::8888
    2 : 2001:4860:4860::8844
  }

which looks a lot like State:/Network/Service/DHCP-tap0/DNS

<dictionary> {
  DomainName : immaculate-conception.net
  ServerAddresses : <array> {
    0 : 192.168.1.254
    1 : 8.8.4.4
    2 : 8.8.8.8
  }
}

3) These don't make it into State:/Network/Global/DNS -- it looks like the 
up/down script needs to handle copying these into State:/Network/Global/DNS -- 
can you point me to where it does this for IPv4?

Original comment by kc9...@gmail.com on 7 Aug 2012 at 2:23

[GoogleCodeExporter]

Here's an overview of client.up.tunnelblick.sh:

The main code starts about line 859. It gets options and initializes some 
variables. Lines 948-971 deal with TAP, with line 962 calling configureDhcpDns 
(when the TAP uses DNS) or line 969 calling ConfigureOpenVpnDns if not.

Those two routines each (in different ways) set up some variables and call 
setDnsServersAndDomainName, which does all the real work.

setDnsServersAndDomainName starts at line 33. It collects MAN_…, CUR_…, and 
DYN_… variables which contain manually-entered DNS/WINS data, current 
DNS/WINS data, and the desired-by-OpenVPN-or-DHCP data, and sets up FIN_… 
variables reflecting what the final result should be. Then (lines 367 - 425) it 
creates SKP_… variables to cause the script to skip certain actions (by 
setting the SKP_… variable to "#" to cause the script to comment out a line).

After some fiddling, the System Configuration database is modified in line 529 
- 541 (for DNS) and lines 543 - 548 (for WINS a/k/a SMB).

One approach would be to load the existing variables with different data if 
IPv6 was active.

A second approach, which I think would be better, is to create one or more new 
sets of variables (MAN_something, CUR_something, DYN_something, and 
SKP_something) that would hold IPv6 info, and deal with that separately. That 
has the advantage of leaving the current code pretty much intact.

Of course, the configureDhcpDns and ConfigureOpenVpnDns routines would also 
need to create new variables to serve as initial "DYN_something" values for the 
new variables. 

I'm still pretty hazy about this, but I hope I gave you enough info to read the 
script more easily.

Original comment by jkbull...@gmail.com on 7 Aug 2012 at 3:32

[GoogleCodeExporter]

Hmm... I'll check this out tomorrow when I'm actually connected to the IPv6 
network rather than tunneled in, but I believe that the difficult part of 
having a separate set of variables is that for DNS, the IPv4 and IPv6 
nameservers for DNS all get thrown together into one configuration -- that is, 
at some point, we need to append the list of IPv6 nameservers to the list of 
IPv4 nameservers and stick them all in the configuration database. I suspect 
that this would be easier to accomplish by having the existing functions simply 
check for IPv6 nameservers in addition to checking for IPv4 nameservers, and 
tack them on the end if they're found. However, this is up for debate.

Original comment by kc9...@gmail.com on 7 Aug 2012 at 3:49

[GoogleCodeExporter]

I think the upshot of this is that for IPv6, DNS/WINS servers should be treated 
the same way as an IPv4 server. We need to grab them from a slightly different 
path, but they're going to the same place.

Original comment by kc9...@gmail.com on 7 Aug 2012 at 4:01

[GoogleCodeExporter]

It's been three years since the last comment, and ipv6 is much more prevalent 
than it used to be.  Any thoughts on getting this in finally? At least for tap 
if nothing else...

Original comment by bugzilla...@gmail.com on 24 Jun 2015 at 5:55