mullvadvpn-app
mullvadvpn-app copied to clipboard
No IPv6 connectivity after waking from sleep
Is it a bug?
- [X] I know this is an issue with the app, and contacting Mullvad support is not relevant.
I have checked if others have reported this already
- [X] I have checked the issue tracker to see if others have reported similar issues.
Current Behavior
Hi there,
so lately i sometimes have blank pages in Firefox and, no websites will load. I'm not getting any error, just a blank page. After some poking around when the issue occurs, i observed:
- Firefox is only resolving an ipv6 ip-address of the website (not ipv4). See screenshot 1.
- The MullvadVPN Desktop app blocks ipv6 by default
- In my Firefox config,
network.trr.mode
is set to0
, which meansoff
(see here. So Firefox is not using DNS-over-HTTPS functionality - Disabling ipv6 in Firefox, "fixes" the issue. See screenshot 2 and 3
Firefox: 124.0.2 (64-bit)
Expected Behavior
.
Steps to Reproduce
Screenshot 1:
(= step 1 above)
Screenshot 2:
(= step 4 above)
Screenshot 3:
(= step 4 above)
Failure Logs
No response
Operating system version
macOS 14.4.1
Mullvad VPN app version
2024.1
Additional Information
No response
...and i'm also seeing the same issue in Alfred workflows for example. So the issue is not limited to Firefox.
So it seems that a 'DNS lookup leak' is happening (Local Network Sharing
is allowed.)
I see DNS lookups to an ipv6 address of my Internet Provider...
Screenshot LittleSnitch:
MullvadVPN Settings:
...and i'm also getting a correct answer. I think Mullvad DNS servers don't return ipv6 addresses, so somehow it's indeed reaching my ISP DNS servers.
"Process" : {
"path" : "\/Applications\/Firefox.app",
"signing ID" : "org.mozilla.firefox",
"pid" : 2072,
"name" : "firefox"
},
"Packet" : {
"Opcode" : "Standard",
"QR" : "Reply",
"Questions" : [
{
"Question Name" : "kagi.com",
"Question Class" : "IN",
"Question Type" : "AAAA "
}
],
"Answers" : [
{
"Name" : "kagi.com",
"Type" : "??",
"Host Address" : "2600:1901:0:daa1::",
"Class" : "IN"
}
],
"RA" : "Recursion available",
"Rcode" : "No error",
"RD" : "Recursion desired",
"XID" : 8375,
"TC" : "Non-Truncated",
"AA" : "Non-Authoritative"
}
}
"Process" : {
"path" : "\/Applications\/Firefox.app",
"signing ID" : "org.mozilla.firefox",
"pid" : 2072,
"name" : "firefox"
},
"Packet" : {
"Opcode" : "Standard",
"QR" : "Reply",
"Questions" : [
{
"Question Name" : "kagi.com",
"Question Class" : "IN",
"Question Type" : "AAAA "
}
],
"Answers" : [
{
"Name" : "kagi.com",
"Type" : "??",
"Host Address" : "2600:1901:0:daa1::",
"Class" : "IN"
}
],
"RA" : "Recursion available",
"Rcode" : "No error",
"RD" : "Recursion desired",
"XID" : 8375,
"TC" : "Non-Truncated",
"AA" : "Non-Authoritative"
}
}
So, i assume the issue is pfctl only blocking DNS lookups via ipv4, and not via ipv6 ?:
pass out quick on utun4 inet proto tcp from any to 100.64.0.31 port = 53 flags S/SA keep state
pass out quick on utun4 inet proto udp from any to 100.64.0.31 port = 53 no state
block return out quick proto tcp from any to any port = 53
block return out quick proto udp from any to any port = 53
Hi,
We're unable to reproduce any leaks using IPv6. Is it possible that you have anchors/rules in PF that are unrelated to Mullvad?
One thing you might try is check whether sudo pfctl -F states
temporarily plugs the leak (while connected).
@dlon Thank you for your reply; I think you might be right, my conclusion was wrong.
-
So it seems these apps are getting the IPv6 address from Mullvad DNS servers (i still have to setup some mechanism to 100% catch all possible DNS leaks, if even possible with DoH these days...)
-
The question is, why are these apps suddenly only trying to connect via IPv6, and no longer via IPv4 ? Because i can still successfully ping and connect to the same domains via ping and other tools. Also, i have now experienced the exact same issue on another Macbook of a different person in the same house.
-
Currently my workaround is to enable IPv6 support in the MullvadVPN Desktop app. This fixes the issue for all apps (Firefox, Obsidian, HomeBrew, etc.) However, the MullvadVPN app GUI says:
"We do not recommend enabling IPv6 unless you know you need it."
Why is it not recommended to enable IPv6 ?
Thank you!
Okay, some more details:
- The issue occurs after the Macbook goes to sleep, and then wakes up
- Chromium browsers (i tried Brave, Chromium, Vivaldi) show errors like this:
screenshot 1
screenshot 2
-
Also connection problems for these apps: Alfred, Obsidian
-
Safari still works fine. Most apps also work fine.
-
Clicking the "Reconnect" arrow in Mullvad, fixes the problem, for all apps.
So I'm currently manually clicking "reconnect" every time my Macbook wakes from sleep, to get working internet...
@dlon PS. please change the title of the issue to something like "Internet connection problems after waking from sleep".
Thank you!
- Clicking the "Reconnect" arrow in Mullvad, fixes the problem, for all apps.
It seems ipv6 no longer works after waking my Macbook from sleep:
after waking from sleep
❯ ping6 kagi.com
PING6(56=40+8+8 bytes) 2001:1c05:1f09:cf00:c87c:6939:27cc:a670 --> 2600:1901:0:daa1::
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
ping6: wrote kagi.com 16 chars, ret=3
^C
--- kagi.com ping6 statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
~ took 8s
after clicking reconnect in the MullvadVPN app
❯ ping6 kagi.com
PING6(56=40+8+8 bytes) fc00:bbbb:bbbb:bb01:d:0:6:8a34 --> 2600:1901:0:daa1::
16 bytes from 2600:1901:0:daa1::, icmp_seq=0 hlim=117 time=25.199 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=1 hlim=117 time=39.798 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=2 hlim=117 time=25.000 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=3 hlim=117 time=71.646 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=4 hlim=117 time=24.836 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=5 hlim=117 time=29.722 ms
16 bytes from 2600:1901:0:daa1::, icmp_seq=6 hlim=117 time=24.843 ms
^C
--- kagi.com ping6 statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 24.836/34.435/71.646/16.009 ms
~ took 6s
...and i can confirm the default ipv6 route has disappeared after waking from sleep:
-
after waking from sleep: 1_after_wake.log
-
after clicking reconnect in the MullvadVPN app: 2_after_mullvad_reconnect.log
...and i can confirm the default ipv6 route has disappeared after waking from sleep:
@dlon So i can reproduce this every time my Macbook goes to sleep. Any idea how to proceed ?
Thank you for debugging this, @notDavid. Timing might be a factor here, which might explain why we cannot reproduce it. I'll get back to you when we've had more time to look into it.