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

1

# Notice to Mullvad customers:

2

3

#

4

5

# For those of you behind very restrictive firewalls,

6

7

# you can use our tunnels on tcp port 443, as well as

8

9

# on udp port 53.

10

11

client

12

13

14

15

dev tun

16

17

18

19

proto udp

20

21

#proto udp

22

23

#proto tcp

24

25

26

27

#remote se.mullvad.net 1300

28

29

#cipher AES-256-CBC

30

31

32

33

#remote openvpn.mullvad.net 443

34

35

#cipher BF-CBC

36

37

38

39

#remote openvpn.mullvad.net 53

40

41

#cipher BF-CBC

42

43

44

45

#remote se.mullvad.net 1300 # Servers in Sweden

46

47

#cipher AES-256-CBC

48

49

50

51

#remote nl.mullvad.net 1300 # Servers in the Netherlands

52

53

#cipher AES-256-CBC

54

55

56

57

#remote de.mullvad.net 1300 # Servers in Germany

58

59

#cipher AES-256-CBC

60

61

62

63

remote us.mullvad.net 1300 # Servers in the USA

64

65

cipher AES-256-CBC

66

67

68

69

# Tunnel IPv6 traffic as well as IPv4

70

71

tun-ipv6

72

73

74

75

# Keep trying indefinitely to resolve the

76

77

# host name of the OpenVPN server. Very useful

78

79

# on machines which are not permanently connected

80

81

# to the internet such as laptops.

82

83

resolv-retry infinite

84

85

86

87

# Most clients don't need to bind to

88

89

# a specific local port number.

90

91

nobind

92

93

94

95

# Try to preserve some state across restarts.

96

97

persist-key

98

99

persist-tun

100

101

102

103

# Enable compression on the VPN link.

104

105

# Don't enable this unless it is also

106

107

# enabled in the server config file.

108

109

comp-lzo

110

111

112

113

# Set log file verbosity.

114

115

verb 3

116

117

118

119

remote-cert-tls server

120

121

122

123

ping-restart 60

124

125

126

127

# Daemonize

128

129

service mullvadopenvpn

130

131

132

133

ping 10

134

135

136

137

ca ca.crt

138

139

cert mullvad.crt

140

141

key mullvad.key

142

143

144

145

crl-verify crl.pem

146

147

148

149

# Limit range of possible TLS cipher-suites

150

151

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

152

153

154

1

client

2

dev tun

3

proto udp

4

remote us.mullvad.net 1300

5

cipher AES-256-CBC

6

tun-ipv6

7

resolv-retry infinite

8

nobind

9

persist-key

10

persist-tun

11

comp-lzo

12

verb 3

13

remote-cert-tls server

14

ping-restart 60

15

service mullvadopenvpn

16

ping 10

17

ca ca.crt

18

cert mullvad.crt

19

key mullvad.key

20

crl-verify crl.pem

21

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

[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.