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