Jump to content
Not connected, Your IP: 3.80.223.123
Staff

The issue "Your browser is avoiding IPv6."

Recommended Posts

What about the issue "Your browser is avoiding IPv6."?

If you use AirVPN servers with IPv6 support:

http://test-ipv6.com: You should obtain a score 10/10. With a single warning:

Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this.

 

http://ipv6-test.com/: You should obtain a score 15/20. The penalty is caused by

 

Browser Default: IPv4" and "Fallback: No

 

 

The reason of the issue is explained here by jd890123 (thank you!):

https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/?do=findComment&comment=81694

 

A quick workaround is also suggested.

 

The issue does not affect Android systems.

 

Share this post


Link to post

At the moment I've got no native IPv6 connection at my disposal to test my hypothesis but I don't think that the problem lies at the application level.

 

The apparent preference for IPv4 does not only seem to prevail in browsers but also in other applications like SSH. If I'm correct, SSH should prefer IPv6 over IPv4 on a native IPv6 connection, if one URL is pointing to multiple DNS entries (A + AAAA in this case). When a connection to a Gen2 server is established (via an IPv4 connection in my case), SSH always prefers IPv4 in my testing. An IPv6 connection to this specific URL can be forced with ssh -6 ... but this shouldn't be the default behavior of SSH.

 

What determines which connection should be preferred?

 

 RFC3484 describes the ranking of competing connections. The resulting /etc/gai.conf on my Arch Linux system looks like this:

 

# All lines have an initial identifier specifying the option followed by
# up to two values.  Information specified in this file replaces the
# default information.  Complete absence of data of one kind causes the
# appropriate default information to be used.  The supported commands include:
#
# reload  <yes|no>
#    If set to yes, each getaddrinfo(3) call will check whether this file
#    changed and if necessary reload.  This option should not really be
#    used.  There are possible runtime problems.  The default is no.
#
# label   <mask>   <value>
#    Add another rule to the RFC 3484 label table.  See section 2.1 in
#    RFC 3484.  The default is:
#
#label ::1/128       0
#label ::/0          1
#label 2002::/16     2
#label ::/96         3
#label ::ffff:0:0/96 4
#label fec0::/10     5
#label fc00::/7      6
#label 2001:0::/32   7
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
#precedence  ::1/128       50
#precedence  ::/0          40
#precedence  2002::/16     30
#precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

 

Which reflects the expected behavior described by the RFC standard. The man-page for this has been implemented in kernel 4.16 (very recently).

 

When I apply the little knowledge I have on IPv6, the ULA each OpenVPN connections gets assigned is part of:

 

label fc00::/7      6

and thus very low in the ranking of the competing connections.

 

Hopefully I could point you in the right direction. If not I'm sorry. I don't understand all of it but this seems plausible to me.

Share this post


Link to post

@kaymio

 

Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address...

 

Kind regards

Share this post


Link to post

kaymio's suspicion is correct, this is caused by the behaviour mandated in RFC 6724.

 

IPv6 is designed for operation by assinging a public (inside 2000::/3) range to each user, addresses in private (ULA) ranges are deliberately picked with low priority.

Your OpenVPN setup instead uses a NAT and assigns private IPs to users, which the RFC does not account for at all.

You can circumvent this bug by assigning addresses from an different, non-ULA and "unused" range: e.g. fe12:34:1234::/48

 

Hope this helps.

Share this post


Link to post

Windows 10 Home

Musica server

 

Chrome 68: 10/10 & 15/20

Edge 42: 10/10 & 18/20*

Firefox 61.0.2: 10/10 & 18/20*

Opera 55.0: 10/10 & 18/20*

 

* Only after clicking the Refresh button on the "Browser" tab.

Every browser had the warning, "Your browser has real working IPv6 address - but is avoiding using it."

Share this post


Link to post

Is there any update about the situation? Using AirVPN I can connect to IPV6-only websites but IPV4 is preferred on all the others.

My isp does not provide native IPV6.

Share this post


Link to post

On windows 7, IPv6 is working by default. On Win 10, this command fixed it (cmd.exe) - netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=active

Premanently fixed by command : netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=persistent

Share this post


Link to post

On windows 7, IPv6 is working by default. On Win 10, this command fixed it (cmd.exe) - netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=active

Premanently fixed by command : netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=persistent

I can confirm that at least the first command works. I scored 10/10 and 19/20.

Share this post


Link to post

@kaymio

 

Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address...

 

Kind regards

 

I have tried to answer the question in much detail at https://gist.github.com/e00E/70bcb5f7f0db216739029a7b7e342fdf .

 

It is an external link because writing a text of this size using this forum's formatting is too tedious.

Share this post


Link to post

I ran the persistent command above. Afterward, I had a problem reaching airvpn.org with a server not found msg. I could reach other sites. After exiting Eddie, I could reach airvpn again. I did a Windows 10 network reset and a netsh Interface reset. Uninstalled and reinstalled Eddie with TAP. After a couple of reboots, IPv4/IPv6 continues to work while Eddie is running and I can connect to airvpn again. While on the VPN, IPv6 test shows browser default is IPv6 with IPv4 fallback < than 1 second for both Firefox and Chrome. 19/20 and 10/10 is the test results. Weird stuff. Also, ipleak.net test is good across the board which also reports IPv6 as browser default with IPv4 fallback.

 

Update 01/19/2019: After doing the resets described above, Both Chrome and Firefox consistently and continuously connect with IPv6 as preferred with IPv4 fallback. Running with Win 10 64bit. Yay! To add, no browser settings were changed within the browser itself.

Share this post


Link to post

After a bit of tinkering I finally get 19/20 on ipv6-test.com running Waterfox 56.2.6 on Debian. I also get 19/20 on Chromium 70 and Firefox ESR (60.4.0). Waterfox addons also indicate that the browser connects to IPv6 addresses all the time. It doesn't seem to be an issue with getaddrinfo() or its config in gai.conf at all as mine is the same as Mr. kaymio's.

 

So, what did I do? I am not entirely sure, to be honest. I disconnected from AirVPN and went on doing experiments on my ISP line with native IPv6. I set

network.http.fast-fallback-to-IPv4;false
network.notify.IPv6;false

and restarted the browser. Then I reenabled the notify setting and restarted again. After that, Firefox/Waterfox magically started to prefer IPv6 and ipv6-test.com gave me 17/20. This is due to my router blocking ICMP (Fritz!Box calls this "Stealth Mode" ) so it should be 19/20 if I decide to stop filtering it.

 

I reconnected to AirVPN and voilà, still prefers IPv6, now 19/20.


Four simple things:
There's a guide to AirVPN. Before you ask questions, take 30 minutes of your time to go through it.

Amazon IPs are not dangerous here. It's the fallback DNS.
Running TOR exits is discouraged. They're subject to restrictions on the internet and harm all AirVPN users.

Furthermore, I propose that your paranoia is to be destroyed. If you overdo privacy, you'll be unique among the mass again.

 

XMPP: gigan3rd@xmpp.airvpn.org or join our lounge@conference.xmpp.airvpn.org

Share this post


Link to post

The gai configuration is the root cause. You have found firefox specific settings that fix the problem which is nice for firefox users but it does not change the behaviour of all the other programs running on your machine.

Share this post


Link to post

I wasn't aware of us talking about all the other programs when the topic is about browsers avoiding IPv6 and the IPv6 test returning 15/20 points, both of which, in my case, are solved now. I will look a bit more into your observation if I get home but it's probably worth a separate thread at this point.

 


 

So, I looked a bit deeper into it. Running Psi, Telegram, Discord, Waterfox and the Minecraft launcher, this is what ss -tupn was telling:

 

$ ss -tupn
Netid       State             Recv-Q        Send-Q                                             Local Address:Port                                              Peer Address:Port                                                            
tcp         ESTAB             0             0                                                  192.168.21.36:35438                                            35.186.224.47:443          users:(("Discord",pid=1172,fd=72))                 
tcp         ESTAB             0             0                                                  192.168.21.36:52584                                            176.34.155.23:443          users:(("waterfox",pid=2740,fd=175))               
tcp         ESTAB             0             0                                                  192.168.21.36:44542                                            143.204.91.67:443          users:(("launcher",pid=4948,fd=56))                
tcp         ESTAB             0             0                                                  192.168.21.36:53228                                           143.204.93.135:443          users:(("launcher",pid=4948,fd=62))                
tcp         ESTAB             0             0                                                  192.168.21.36:58338                                             169.55.74.49:443          users:(("waterfox",pid=2740,fd=72))                
tcp         ESTAB             0             0                                                  192.168.21.36:53232                                           143.204.93.135:443          users:(("launcher",pid=4948,fd=66))                
tcp         CLOSE-WAIT        1             0                                                  192.168.21.36:44908                                            34.193.223.42:443          users:(("launcher",pid=4948,fd=59))                
tcp         ESTAB             0             0                                                  192.168.21.36:53220                                           143.204.93.135:443          users:(("launcher",pid=4948,fd=55))                
tcp         CLOSE-WAIT        1             0                                                  192.168.21.36:41044                                             13.35.242.10:80           users:(("plasma-browser-",pid=2998,fd=114))        
tcp         ESTAB             0             0                                                  192.168.21.36:37828                                             104.16.60.37:443          users:(("Discord",pid=1172,fd=73))                 
tcp         CLOSE-WAIT        1             0                                                  192.168.21.36:45438                                             46.51.179.90:443          users:(("plasma-browser-",pid=2998,fd=101))        
tcp         ESTAB             0             0                                                  192.168.21.36:41160                                           149.154.167.51:443          users:(("Telegram",pid=1170,fd=16))                
tcp         ESTAB             0             0                                                  192.168.21.36:52504                                             54.77.207.75:5222         users:(("psi",pid=1184,fd=21))                     
tcp         CLOSE-WAIT        32            0                                                  192.168.21.36:53230                                           143.204.93.135:443          users:(("launcher",pid=4948,fd=64))                
tcp         CLOSE-WAIT        1             0                                                  192.168.21.36:44906                                            34.193.223.42:443          users:(("launcher",pid=4948,fd=57))                
tcp         ESTAB             0             0                                                  192.168.21.36:53264                                              80.67.16.35:443          users:(("waterfox",pid=2740,fd=123))               
tcp         ESTAB             0             0                                                  192.168.21.36:49774                                           34.213.248.229:443          users:(("waterfox",pid=2740,fd=71))                
tcp         ESTAB             0             0                                                  192.168.21.36:33258                                           143.204.93.135:80           users:(("launcher",pid=4948,fd=58))                
tcp         ESTAB             327           0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:42698                    [2600:9000:200d:2400:b:c94:bc00:93a1]:443          users:(("launcher",pid=4948,fd=67))                
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:49196                               [2a00:1450:4001:821::200e]:443          users:(("launcher",pid=4948,fd=54))                
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:53152                      [2a03:2880:f22d:c5:face:b00c:0:167]:443          users:(("waterfox",pid=2740,fd=166))               
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:49494                 [2a05:d014:ef7:d001:e6fd:ca68:96fe:acc1]:443          users:(("waterfox",pid=2740,fd=171))               
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:46310                               [2a00:1450:4001:81e::200e]:443          users:(("launcher",pid=4948,fd=51))                
tcp         ESTAB             0             0                                         [::ffff:192.168.21.36]:33824                                   [::ffff:192.168.21.12]:1716         users:(("kdeconnectd",pid=1097,fd=18))             
tcp         CLOSE-WAIT        278           0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:50894                      [2a03:2880:f22d:c5:face:b00c:0:167]:443          users:(("plasma-browser-",pid=2998,fd=100))        
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:50282                 [2a02:8108:8ac0:750:xxxx:xxff:fexx:xxxx]:443          users:(("waterfox",pid=2740,fd=176))               
tcp         ESTAB             327           0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:42700                    [2600:9000:200d:2400:b:c94:bc00:93a1]:443          users:(("launcher",pid=4948,fd=68))                
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:42696                    [2600:9000:200d:2400:b:c94:bc00:93a1]:443          users:(("launcher",pid=4948,fd=65))                
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:33138                                   [2606:4700::6811:c8f0]:443          users:(("waterfox",pid=2740,fd=95))                
tcp         CLOSE-WAIT        47            0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:35720                 [2a05:d014:ef7:d003:67bf:b27b:e1c9:efbc]:443          users:(("plasma-browser-",pid=2998,fd=95))         
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:40448                  [2a02:8108:8ac0:750:xxxx:xxff:fexx:xxxx]:8080         users:(("waterfox",pid=2740,fd=77))                
tcp         ESTAB             0             0                       [2a02:8108:8ac0:750:6b88:9453:3ac6:4228]:50238                 [2a02:8108:8ac0:750:xxxx:xxff:fexx:xxxx]:443          users:(("waterfox",pid=2740,fd=42))                

Discord, Telegram, WhatsApp Web (over Waterfox) and Air's XMPP servers don't have AAAA records at all so it's obvious why they would connect over v4. Steam would do the same, I think (no AAAAs on (store.)steampowered.com, either).

 

The Minecraft launcher seemed to have something to do with v6 (connecting to 2a00:1450:4001:81e::200e which is a 1e100.net IP, so Google and therefore guaranteed IPv6 connectivity) but connected to mcoapi.minecraft.net and Mojang's authserver over v4 because both, again, don't have an AAAA record.

 

Then I edited the nameservers of my domain and created an AAAA entry directly to a certain Minecraft server but Minecraft didn't want to connect at all ("No route to host"). Adding an A record did it. Now, I'm not a Java developer, but isn't Netty supposed to support IPv6 or is it up to the code that uses it?

 

It does, but it prefers local IPv4. Hm.

 

That's all I found for now.

Edited ... by giganerd

Four simple things:
There's a guide to AirVPN. Before you ask questions, take 30 minutes of your time to go through it.

Amazon IPs are not dangerous here. It's the fallback DNS.
Running TOR exits is discouraged. They're subject to restrictions on the internet and harm all AirVPN users.

Furthermore, I propose that your paranoia is to be destroyed. If you overdo privacy, you'll be unique among the mass again.

 

XMPP: gigan3rd@xmpp.airvpn.org or join our lounge@conference.xmpp.airvpn.org

Share this post


Link to post

For those running Windows 10 and don't want to run the persistent command but still want the IPV6 by default, you can do so via Eddie.

 

Open up Preferences, Go To Events, open the VPN Up (or anything above it, I don't know if it matters) option.

For file name navigate to C:/Windows/System32/netsh.exe

For argument type: interface ipv6 set prefixpolicy fc00::/7 37 1 store=active

I have "Wait end of process" disabled, but I don't know if that matters.

Click Save.

Reconnect to an AirVPN server.

You should now have IPV6 by default any time you connect to a server, and upon reboot, it will reset back to normal.

 

It would probably be idea if the VPN Down option had something resetting the Netsh settings, but I don't know how to do that.

 

Also Microsoft apparently says Netsh might be removed in the future for a powershell option so... ¯\_(ツ)_/¯

Share this post


Link to post

×
×
  • Create New...