Problems with Browser Default Protocol and Fallback

[bimmerdriver]

I'm using Mullvad's VPN service, which is based on openvpn, on a windows client. (FYI, I'm a satisfied Mullvad user and I'm happy with their support, but we have not been able to identify the cause of the issues I'm posting about here. I have discussed posting here with them and they have no problems with it.) I have ipv6 enabled. I use ipv6-test.com and test-ipv6.com to ensure things are working properly. I've found that ipv6 through openvpn is unreliable, and in particular, the browser default protocol and fallback do not behave the same through openvpn as they do using either native ipv6 or a hurricane electric tunnel.

I've tested using windows 7 and windows 10. I've tested used chrome, IE11 and edge. I've tested using Mullvad's client (several versions, including the latest, 60) and the latest openvpn client (2.3.12-1601). My router is pfsense. I've tested using openvpn through pfsense 2.3.1 with a hurricane electric tunnel and through pfsense 2.3.3 development with native ipv6. I've tested using all of Mullvad's servers around the world.

The symptoms are the following:

Using test-ipv6.com, it gives a 10/10 score but reports "Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this."

Using ipv6-test.com, it gives a 19/20 score, but reports the browser default protocol is ipv4 and the fallback to ipv6 is unreliable. The fallback is really strange. The first time I run the test, it takes a long time and fails. If I run it to completion several times in a row, it starts working better. It might report "Fallback to ipv6 in 15 seconds" (or whatever), then fail again, then after a few times, it reports "Fallback to ipv6 in <1 second". If I keep refreshing the browser, it will get the same result. If I leave it alone for a few minutes, it will degrade. For curiosity, I tried refreshing it over and over for a few minutes to see if that would cause the browser to change to ipv6, but it did not. Maybe I didn't try it enough times.

When I disable openvpn, both tests consistently pass with 10/10 and 20/20, respectively and the browser defaults to ipv6. The results are the same, virtually 100% of the time.

It's as if there is a problem in the ipv6 support of openvpn. I'm wondering if anyone here has experienced the same thing and if there is a solution.

My client configuration is below:

View OriginalClient Configuration

# Notice to Mullvad customers:
#
# For those of you behind very restrictive firewalls,
# you can use our tunnels on tcp port 443, as well as
# on udp port 53.
client

dev tun

proto udp
#proto udp
#proto tcp

#remote se.mullvad.net 1300
#cipher AES-256-CBC

#remote openvpn.mullvad.net 443
#cipher BF-CBC

#remote openvpn.mullvad.net 53
#cipher BF-CBC

#remote se.mullvad.net 1300 # Servers in Sweden
#cipher AES-256-CBC

#remote nl.mullvad.net 1300 # Servers in the Netherlands
#cipher AES-256-CBC

#remote de.mullvad.net 1300 # Servers in Germany
#cipher AES-256-CBC

remote us.mullvad.net 1300 # Servers in the USA
cipher AES-256-CBC

# Tunnel IPv6 traffic as well as IPv4
tun-ipv6

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Try to preserve some state across restarts.
persist-key
persist-tun

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

remote-cert-tls server

ping-restart 60

# Daemonize
service mullvadopenvpn

ping 10

ca ca.crt
cert mullvad.crt
key mullvad.key

crl-verify crl.pem

# Limit range of possible TLS cipher-suites
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-SEED-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

block-outside-dns

[bimmerdriver]

I'd really appreciate if anyone using openvpn with ipv6 enabled is experiencing the same issues that I described in the original post, which are defaulting to ipv4 rather than ipv6 and having intermittently slow fallback to the alternate protocol. Unless there is a problem with all of Mullvad's server configurations, this seems like a problem with openvpn.