search

mullvad / mullvadvpn-app

The Mullvad VPN client app for desktop and mobile
https://mullvad.net/
GNU General Public License v3.0
4.65k stars 329 forks source link

No IPv6 connectivity after waking from sleep #6078

Open notDavid opened 3 months ago

notDavid commented 3 months ago

Is it a bug?

I have checked if others have reported this already

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:

  1. Firefox is only resolving an ipv6 ip-address of the website (not ipv4). See screenshot 1.
  2. The MullvadVPN Desktop app blocks ipv6 by default
  3. In my Firefox config, network.trr.mode is set to 0, which means off (see here. So Firefox is not using DNS-over-HTTPS functionality
  4. 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)

1-issue-occurs

Screenshot 2:

(= step 4 above)

2-disable-ipv6

Screenshot 3:

(= step 4 above)

3-works-without-ipv6

Failure Logs

No response

Operating system version

macOS 14.4.1

Mullvad VPN app version

2024.1

Additional Information

No response

notDavid commented 3 months ago

...and i'm also seeing the same issue in Alfred workflows for example. So the issue is not limited to Firefox.

Screenshot 2024-04-10 at 17 11 39@2x

notDavid commented 3 months ago

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: ![LS](https://github.com/mullvad/mullvadvpn-app/assets/1530401/1a373f10-fbec-4bf6-a740-3d92ee875cfe)
MullvadVPN Settings: MullvadSettings
notDavid commented 3 months ago

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

<-- Firefox DNS lookup answer ```log "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
dlon commented 2 months ago

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

notDavid commented 2 months ago

@dlon Thank you for your reply; I think you might be right, my conclusion was wrong.

  1. 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...)

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

  3. 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!

notDavid commented 2 weeks ago

Okay, some more details:

mullvad_browser_error_1

screenshot 2 mullvad_browser_error_2

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!

notDavid commented 2 weeks ago
  • 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
notDavid commented 2 weeks ago

...and i can confirm the default ipv6 route has disappeared after waking from sleep:

notDavid commented 3 days ago

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

dlon commented 2 hours ago

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.