...

As you might have noticed there is a NAT64 SSID. This thread is for complains about that network.

Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong.

if you have network issues while using that SSID and switching to dual-stack one fixes the problem - please reply to this thread (indeed you can create a new one, I was just thinking that keeping everything in one thread might make our life easier but I might be wrong...).

Thanks Jen,

May I suggest people include device make and model and software versions involved when complaining about application or OS behaviour?

Makes it easier to run statistics and assessing how big the impact on the total user population would be, if one would deploy this technique in production environment.

Very good point indeed, thanks Marco! It would be great if complains would include troubleshooting info whenever possible - as much as reporting user is willing/able to collect and share. -- SY, Jen Linkova aka Furry

Hi Gert / All, On 16 November 2015 at 14:28:01, Gert Doering (gert@space.net) wrote: Hi,  On Mon, Nov 16, 2015 at 01:19:08PM +0100, Piotr Strzyzewski wrote: 

On Mon, Nov 16, 2015 at 12:55:57PM +0100, Jen Linkova wrote: 

...

Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong.    OpenVPN 2.3.8 from Win 8.1 Pro 64bit (if that matters) to v4 only host  don't want to connect. 

Yeah, sorry for that. OpenVPN 2.3 is not proper dual-stacked, more  "doubly single-stacked" - so it works if you do "--proto udp6" to  make it ask for an AAAA record, but it will not try both protocols  automatically.  OpenVPN 2.4 (which is "git master and daily snapshots" now) will do  the right thing - getaddrinfo() and try all v4 and v6 addresses returned.  Snapshots are here:  http://build.openvpn.net/downloads/snapshots/  (and the general quality of recent snapshots is good enough you can use  them fairly safely)  Seems there’s only Windows binaries… I can’t seem to find MacOS version of OpenVPN 2.4? Cheers, —  Nico

Hi Gert, On 18 November 2015 at 15:33:58, Gert Doering (gert@space.net) wrote: […] Well, "we" (as the openvpn team) don't do MacOS binaries - because it's  basically easy to compile it yourself :-) - do git clone, autoreconf -vif,  make (possibly compiling and installing LZO first).   The resulting openvpn binary can then be used directly or copied into the  Tunnelblick bundle, and it will get used by the GUI...  My mistake, I’ll do it this way, thanks for the quick answer! Cheers, —  Nico

Gert, On 19 November 2015 at 18:30:54, Gert Doering (gert@space.net) wrote: Hi,  On Wed, Nov 18, 2015 at 03:23:34PM +0200, Nico CARTRON wrote: 

Seems there???s only Windows binaries??? I can???t seem to find MacOS version of OpenVPN 2.4? 

Speak, and your wishes shall be granted :-)  I just received this nice announcement...  ---------------------------------------------------------------  From: jkbull..gmail.com <jkbullard@gmail.com>  Date: Thu, Nov 19, 2015 at 4:10 PM  Subject: Tunnelblick 3.6beta12 is available  To: tunnelblick-announce <tunnelblick-announce@googlegroups.com>  Tunnelblick 3.6beta12 is available for *download*  <https://tunnelblick.net/downloads.html>.  Changes since Tunnelblick 3.6beta10:  - Includes OpenVPN git-master as of commit 7546cba (2015-11-13), in  addition to 2.3.7 and 2.3.8.  ...  ---------------------------------------------------------------  so - if you install this tunnelblick beta, there is a "settings" item  where you can select which openvpn binary should be run. This used to  be 2.3.7 and 2.3.8, and now Jonathan was so nice to add a -current snapshot  to it... no need to compile your own anymore :-)  Well, this is what I call efficiency! Just downloaded this version, and boom, it worked!!! Thanks very much for the follow-up! All the best, —  Nico

On Mon, Nov 16, 2015 at 1:45 PM, Timo Hilbrink <timo@xs4all.net> wrote:

On 16/11/2015 12:55, Jen Linkova wrote:

...

Hi guys,

As you might have noticed there is a NAT64 SSID. This thread is for complains about that network.

Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong.

My phone can't connect to this SSID, HTC One S, Android 4.1.1

It hangs on 'Authenticating', gives up after a while, and marks the SSID with 'Avoided poor internet connection' :)

It is known issue fixed in Android 5-smth. What's happening is the device is trying to get v4 address. What you could do it to manually configure v4 address (any address, 192.0.2.2 would do) and, indeed, DNS64 as DNS server (which seems to be 2001:67c:64:47::c100:1fee). -- SY, Jen Linkova aka Furry

I may be looking at something that isn't expected to work in this set-up at all, but still: traceroute to my workstation back home in "default" command-line does not work, it comes back with "network is unreachable". Adding -6 flag to force using the AAAA DNS response makes it work. According to the man page it should select the version automatically. Requesting TCP mode fails completely to come back with answers, even when forcing -6 Linux Mint Quiana, 32bit, Modern traceroute for Linux, version 2.0.20, Aug 19 2014 Copyright (c) 2008 Dmitry Butskoy, License: GPL v2 or any later Fwiw, Wilfried

Hi Jen and v6 aficionados, please disregard, there seems to be a mix-up with the versions of traceroute and tcptraceroute I did install just recently. tcptraceroute seems to have no support for -6 and traceroute seems to recognize -4 and -6, but -P tcp fails for both. Sorry, Wilfried On 2015-11-16 17:05, Jen Linkova wrote:

On Mon, Nov 16, 2015 at 3:22 PM, Wilfried Woeber <woeber@cc.univie.ac.at> wrote:

...

I may be looking at something that isn't expected to work in this set-up at all, but still:

traceroute to my workstation back home in "default" command-line does not work, it comes back with "network is unreachable". Adding -6 flag to force using the AAAA DNS response makes it work. According to the man page it should select the version automatically.

Requesting TCP mode fails completely to come back with answers, even when forcing -6

So does TCP mode work for Ipv6 address on the dual-stack network?

Den 2015-11-17 kl. 13:52, skrev Luuk Hendriks:

On Mon 16 Nov 2015, 12:55, Jen Linkova wrote:

...

As you might have noticed there is a NAT64 SSID. This thread is for complains about that network.

Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. Unsure how related to the nat64 network, but I lost connectivity around 14:42:39 local time. Had to re-associate in order to get things back to work.

It's probably not related to nat64 and you are not alone. Many with something different from Windows/Mac do have problems with the wifi. It's been like this since RIPE65. And for the record. I've been to the technical support several times during the meetings. Mind you, not this one. My colleague did.

Arch Linux x86_64, 4.2.5-1-ARCH

Name : wpa_supplicant Version : 1:2.3-1

Name : netctl Version : 1.11-1

luuk

-- Bengt Gördén Resilans AB

On Tue, Nov 17, 2015 at 2:22 PM, Job Snijders <job@instituut.net> wrote:

...

Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong.

I can't get it to work on my "Blackberry Classic (SQC100-1)" with BBOS 10.3.2.2474. Unsure what the current state of IPv6 support on BBOS is, it appears the device has an IPv6 link-local address on the WiFi interface, but it doesn't have a global address. I don't know why, maybe it doesnt speak the proper bootstrap protocol.

Does it get IPv6 address while connecting to the dual-stack SSID? If yes, does it use it (http://ipv6.test-ipv6.com/)? -- SY, Jen Linkova aka Furry

F5 VPN set-up plug-in for Firefox, to support dial-factor authentication, fails without some manual help. Although the server host is visible with a v6 address in DNS, the plug-in fails to connect to the server. Inserting the IPv6 address literal into the URL makes it connect. Again, selecting YubiKey as the secondary auth again fails to load the page. Supplying the v6 literal allows to load the page, collects the credentials and successfully establishes the tunnel. So, this animal can be educated to do what is needed, but it needs manual intervention. Wilfried

Dne 18.11.2015 v 12:19 Ondřej Caletka napsal(a):

But that has been marked as fixed. Maybe a new one should be opened.

Opened here: https://bugzilla.mozilla.org/show_bug.cgi?id=1225783 -- Ondřej