Tunnelblick on an IPv6-only network?

[mel...@gmail.com]

I'm at the IETF trying to get by with just IPv6 for the week, and I discovered that one of the things that doesn't work on IPv6 is Tunnelblick.   Has anybody experimented with this, or should I fend for myself?

[Molina-Bulla Harold]

Hi,

Yes, I have IPv6 working in my OpenVPN infrastructure:

IPv6 over IPv4 tunnel and IPv6 over IPv6 tunnel, using udp an tcp carrier protocol..

The only think which I have not is OpenVPN server dual stacked, due it had problems with OpenVPN Connect client for iOS.

The main trick is in the server:

topology subnet

server-ipv6 IPV6_ADDRESS_AND_SEGMENT_TO_SHARE/MASKSIZE_TO_SHARE

tun-ipv6

and if you wish to route all the IPv6 traffic through your tunnel, use:

push "route-ipv6 2000::/3"

In the client you do not need to change anything (you must use OpenVPN 2.3.1 or higher, do not use 2.3.0, because have a TCP stack overflow problem)

If you have more questions, please do not hesitate asks.

H.

-----------------------------------------------------------------

- "¿Existe el Gran Hermano?" - Winston

- "Claro que existe. El Partido existe. El Gran Hermano es la 

  encarnación del partido." - O'Brien

- "¿Existe en el mismo sentido en que yo existo?" - Winston

- "Tú no existes." - O'Brien 

George Orwell (1984)

-----------------------------------------------------------------

Recuerda: PRISM te está vigilando!!! X)

Y tu no existes!!!

-----------------------------------------------------------------

Harold Molina-Bulla Ph.D.

h.mo...@gmail.org

Profesor Visitante/Visiting Lecturer

Clave GnuPG: D727746B

On Jul 30, 2013, at 21:19 , mel...@gmail.com wrote:

I'm at the IETF trying to get by with just IPv6 for the week, and I discovered that one of the things that doesn't work on IPv6 is Tunnelblick.   Has anybody experimented with this, or should I fend for myself?

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jkbull...gmail.com]

If you use Tunnelblick 3.3.0, it includes OpenVPN 2.3.2, which I believe supports IPv6. You can select it on the "Preferences" panel of the "VPN Details…" window.

As far as I know Tunnelblick itself is limited to IPv4 in the following places:

• The "Set DNS/WINS" scripts (you must specify "Do not set nameserver" in the "Settings" tab of each configuration and supply your own up/down scripts)
  
• The "Check if the apparent public IP address changed after connection" feature (disable this on the "Preferences" panel of the "VPN Details…" window. (If Tunnelblick can't access tunnelblick.net by name after a VPN is connected, it uses the tunnelblick.net IPv4 address to try to access it. (Figuring that if that succeeds, there is a DNS problem and if if fails there is a general connectivity -- e.g. routing -- problem.)

I think that the update mechanism, Sparkle, should be IPv? independent, although I'm just guessing.

If you develop up/down scripts for IPv6 or modify the current scripts for IPv6, it would be great if you shared them! I'd be glad to try to integrate them into Tunnelblick. The current default scripts (when you select "Set nameserver") are Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh and client.down.tunnelblick.sh, and client.route-pre-down.tunnelblick.sh (which is used to release DHCP on a TAP connection).

The standard scripts may be overridden by including "up.tunnelblick.sh" and "down.tunnelblick.sh" scripts in aTunnelblick VPN Configuration. It isn't documented, but I think you also can include "route-pre-down.tunnelblick.sh" to override that script.

Any help on IPv6 would be very welcome.

[Molina-Bulla Harold]

Hi Jonathan,

I had my VPN working with IPv6 a few months a go, and I do not need to change anything in the TunnelBlick scripts.

The only thing, if I am using only IPv6, is define the name servers, like:

push "dhcp-option DNS fec0::1040:a176:2b1e:3e30:ec42"

push "dhcp-option DNS fec0::1040:a176:2b1c:3e57:81f1"

And the TunnelBlick provided scripts works well.

 

Best regards.

H.

-----------------------------------------------------------------

- "¿Existe el Gran Hermano?" - Winston

- "Claro que existe. El Partido existe. El Gran Hermano es la 

  encarnación del partido." - O'Brien

- "¿Existe en el mismo sentido en que yo existo?" - Winston

- "Tú no existes." - O'Brien 

George Orwell (1984)

-----------------------------------------------------------------

Recuerda: PRISM te está vigilando!!! X)

Y tu no existes!!!

-----------------------------------------------------------------

Harold Molina-Bulla Ph.D.

h.mo...@gmail.org

Clave GnuPG: D727746B

[Jonathan K. Bullard]

Hi Harold -- thanks again for your earlier work on getting OpenVPN 2.3 to build Tunnelblick and the 64-bit builds.

I'm surprised that the standard scripts work, because they set OS X "IPv4" networking keys. But maybe if you set the IPv4 keys to IPv6 values OS X uses them for IPv6. That would be great!

[Ted Lemon]

Wow, thanks for the advice, everyone!   I am running 3.3.0, but it reports that the openvpn version is 2.2.1, not 2.3.1.   I don't remember installing openvpn separate from Tunnelblick, but it's been a while.   I hunted around on my system and couldn't find an openvpn install anywhere.   Is it part of the Tunnelblick binary, or is there a step I missed?

[Molina-Bulla Harold]

Hi Ted,

Tunnelblick comes with OpenVPN 2.3.2.

Go to TunnelBlick->VPN Details and select "Preferences" Tab.

There you can find the "OpenVPN version" where you can select the OpenVPN version to use.

One tip: Select the Labeled "Latest", because, if in further TunnelBlick distributions changes the OpenVPN version selects the latest one (and do not back to 2.2.1)

Best regards.

H.

-----------------------------------------------------------------

- "¿Existe el Gran Hermano?" - Winston

- "Claro que existe. El Partido existe. El Gran Hermano es la 

  encarnación del partido." - O'Brien

- "¿Existe en el mismo sentido en que yo existo?" - Winston

- "Tú no existes." - O'Brien 

George Orwell (1984)

-----------------------------------------------------------------

Recuerda: PRISM te está vigilando!!! X)

Y tu no existes!!!

-----------------------------------------------------------------

Harold Molina-Bulla Ph.D.

h.mo...@gmail.org

Clave GnuPG: D727746B

On Jul 30, 2013, at 23:45 , Ted Lemon <mel...@gmail.com> wrote:

Wow, thanks for the advice, everyone!   I am running 3.3.0, but it reports that the openvpn version is 2.2.1, not 2.3.1.   I don't remember installing openvpn separate from Tunnelblick, but it's been a while.   I hunted around on my system and couldn't find an openvpn install anywhere.   Is it part of the Tunnelblick binary, or is there a step I missed?

[Jonathan K. Bullard]

I'm don't know what name servers Harold is referencing in

push "dhcp-option DNS fec0::1040:a176:2b1e:3e30:ec42"

push "dhcp-option DNS fec0::1040:a176:2b1c:3e57:81f1"

To use the Google Public DNS servers, I think you could use

push "dhcp-option DNS 2001:4860:4860::8888"

push "dhcp-option DNS 2001:4860:4860::8844"

(Those IPv6 addresses come from Using Google Public DNS [google.com])

On Tue, Jul 30, 2013 at 3:56 PM, Molina-Bulla Harold <h.mo...@gmail.com> wrote:

[Ted Lemon]

Okay, now I am getting a little more life out of it, but what's happening now is that even though I don't have an IPv4 address configured on the interface, it's doing an A record query and getting an A record back, and then trying to connect to that IPv4 address, rather than doing a AAAA lookup and trying to connect to the AAAA record.   So this looks like a bug in openvpn, not Tunnelblick.   I am very happy to help debug this, but probably not during IETF, unfortunately.   Because I'm using a NAT64 setup, I can't get rid of the A record, but I'm pretty sure this is why it's failing, so I don't mind just waiting until I have time and fixing it myself.

[Molina-Bulla Harold]

Hi Ted,

How are you making your tests?

The behaviour described looks like you are using PING or TRACEDUMP.

If you search an IP address using host, nslookup, or dig, these tools will return both records (A and AAAA), that means the mDNSResolver cache will stores both addresses. For other applications depending which application are you using, they will use IPv4 or IPv6.

For example:

ping will use ALWAYS ipv4. If you wants to test IPv6, must use ping6

The same thing with tracedump -> tracedump6

ssh, by default, will tries first IPv6 (if available) and after IPv4.

Google Chrome uses IPv4 unless you reconfigure to use IPv6 too. Then it will try first IPv6 and if in 0.5 secs the server do not responds, tries IPv4. After that he will uses the fastest link.

Firefox implements the same algorithm (but you do not need reconfigure them to support IPv6).

etc…

Best regards.

H.

-----------------------------------------------------------------

- "¿Existe el Gran Hermano?" - Winston

- "Claro que existe. El Partido existe. El Gran Hermano es la 

  encarnación del partido." - O'Brien

- "¿Existe en el mismo sentido en que yo existo?" - Winston

- "Tú no existes." - O'Brien 

George Orwell (1984)

-----------------------------------------------------------------

Recuerda: PRISM te está vigilando!!! X)

Y tu no existes!!!

-----------------------------------------------------------------

Harold Molina-Bulla Ph.D.

h.mo...@gmail.org

Clave GnuPG: D727746B

On Jul 31, 2013, at 08:22 , Ted Lemon <mel...@gmail.com> wrote:

Okay, now I am getting a little more life out of it, but what's happening now is that even though I don't have an IPv4 address configured on the interface, it's doing an A record query and getting an A record back, and then trying to connect to that IPv4 address, rather than doing a AAAA lookup and trying to connect to the AAAA record.   So this looks like a bug in openvpn, not Tunnelblick.   I am very happy to help debug this, but probably not during IETF, unfortunately.   Because I'm using a NAT64 setup, I can't get rid of the A record, but I'm pretty sure this is why it's failing, so I don't mind just waiting until I have time and fixing it myself.

[Ted Lemon]

I have figured out what the problem is.   The problem is that openvpn doesn't actually support dual-stack destinations.   So if you have a v6-only destination, you can connect to it by explicitly selecting a v6 transport.   But if you have a dual-stack destination, you can only always connect to it on ipv4 or only connect to it on ipv6, or treat it as two destinations.   But there's no way to take your config file that worked on ipv4 and use it on ipv6.   It sounds like this is a known problem, so I will just use the workaround, which does in fact work on the ietf-nat64 network.

Thanks to everyone for all your attempts to figure out why I'm losing. :)