Slow initial loading of websites on Windows (DNS?)

[Geblaat]

Issue report

Operating system: Windows 21H1 x64 App version: 2022.3 - 2022.5

Issue description

When using 2022.2 with Wireguard, website loading was very fast. At some point I tried 2022.3-beta-2. The initial loading of websites then became extremely slow. Once it starts loading the speed is good, and I can get 30MB/s+ when downloading, so throughput is not an issue. The initial loading takes a long time though. So maybe it is a DNS issue? Autocomplete of search words and tags is also really slow. 2022.3 final and 2022.4 have the same issue. 2022.5 is faster, but still definitely not as fast as 2022.2 If I switch back to 2022.2 everything is fast again.

[GibMeMyPacket]

Let me link you to THIS which was the case for me, so i had to decrease the amount of hosts in HOSTS file. This case doesn't relate to Mullvad.

[Geblaat]

Let me link you to THIS which was the case for me, so i had to decrease the amount of hosts in HOSTS file. This case doesn't relate to Mullvad.

Thanks for you suggestion. But I don't have any entries in my Hosts file.

[dlon]

Does this issue affect all software or only some of it (like your browser)? It sounds like the tunnel adapter is being used as a fallback for DNS queries instead of being the primary adapter.

You could try disabling all adblocking features and seeing if running this (in a command prompt) helps:

netsh interface ipv4 set dnsservers name="Mullvad" source=static address=10.64.0.1 validate=no

If that doesn't work, also check if any of your network interfaces have a lower metric than the tunnel interface. Use Get-NetIPInterface in PowerShell. If any metric value is equal to or lower than that of the "Mullvad" interface(s), consider increasing it. The metric value of "Mullvad" should be 1.

[Geblaat]

Does this issue affect all software or only some of it (like your browser)? It sounds like the tunnel adapter is being used as a fallback for DNS queries instead of being the primary adapter.

It seems to affect all software.

You could try disabling all adblocking features and seeing if running this (in a command prompt) helps:

netsh interface ipv4 set dnsservers name="Mullvad" source=static address=10.64.0.1 validate=no

I wasn't using any blocking features from Mullvad and the command does not help. Should I revert this command?

If that doesn't work, also check if any of your network interfaces have a lower metric than the tunnel interface. Use Get-NetIPInterface in PowerShell. If any metric value is equal to or lower than that of the "Mullvad" interface(s), consider increasing it. The metric value of "Mullvad" should be 1.

The metric value of Mullvad is already 1 and there are no interfaces with an equal value.

[LinuxOnTheDesktop]

I have the same or at least a similar problem: websites, or at least some of them, are, intermittently, slow to load. And none of the procedures recommended above helped. Also, intermittently, various sites, including Amazon, fail to load at all. I'm using Firefox on Windows, and Wireguard. Just now I've enabled the Firefox proxy; I will see whether that helps.

EDITED.

[dlon]

@Geblaat

Thanks for the response. Please send a problem report if you haven't done so. :)

Does enabling/disabling IPv6 in the app make any difference? Also, is the correct resolver being used (10.64.0.1) when you run nslookup mullvad.net and/or Resolve-DnsName mullvad.net?

@LinuxOnTheDesktop

That sounds like an unrelated problem. You might be better off contacting support@mullvad.net if you believe that it is related to Mullvad.

[Geblaat]

@Geblaat

Thanks for the response. Please send a problem report if you haven't done so. :)

Does enabling/disabling IPv6 in the app make any difference? Also, is the correct resolver being used (10.64.0.1) when you run nslookup mullvad.net and/or Resolve-DnsName mullvad.net?

I enabled IPv6 in the app, but there was no difference. Indeed the correct resolver is being used when I use nslookup. I just send a problem report with a mention of this github issue.

[dlon]

@Geblaat Thank you for that. Could you give the following dev build a go? https://releases.mullvad.net/builds/2022.5-dev-8aaedf+test-win-netsh/MullvadVPN-2022.5-dev-8aaedf+test-win-netsh.exe

[Geblaat]

@Geblaat Thank you for that. Could you give the following dev build a go? https://releases.mullvad.net/builds/2022.5-dev-8aaedf+test-win-netsh/MullvadVPN-2022.5-dev-8aaedf+test-win-netsh.exe

Yes, I've been running it for 2 days now, but it doesn't really make a difference. I installed it on top of 2022.5, but I did reboot after just to be sure.

[Geblaat]

@dlon did you see my last reply? Is there anything else I can do/test?

[dlon]

@Geblaat Sorry for the slow response. If you just want to work around this issue, you could probably just enable DNS over HTTPS in Firefox.

Alternatively, run the following powershell command:

Add-DnsClientNrptRule -Namespace "." -NameServers "10.64.0.1"

This will work unless you're using any of the DNS content blockers or custom DNS. In that case, adjust the address (10.64.0.1) accordingly. You will have to run Remove-DnsClientNrptRule to remove the rule when disconnected from the VPN, or DNS resolution won't work while disconnected.

As for the actual problem, run [System.Net.DNS]::GetHostByName('mullvad.net') (soon after reconnecting, to ensure that the entry is not cached). If this is not slow, your issue probably isn't DNS related or it is somehow related to Firefox. If these queries are also slow, there are many possible explanations, so I won't enumerate all of them. I would first try to figure out if one of your other network interfaces is somehow causing this.

[Geblaat]

@dlon Thanks for the reply. I'm using mostly Brave but it seems to affect all browsers. Enabling DNS over HTTPS does not solve the problem. Running [System.Net.DNS]::GetHostByName('mullvad.net') or for other sites is still fast. So it doesn't seem to be a DNS issue. Secondly, the slow initial loading of sites in the webbrowser still happens subsequent times, so if it was a DNS issue you would expect it to be fast subsequent times because of caching.

It is still fast most of the time when the computer has just been booted up. Maybe it slows down due to the torrent client with lots of loaded torrents. But if that is the case, it would be weird that 2022.2 is not affected. I also have multiple virtual network adapters from VMware, Virtualbox and Hyper-V.

[Geblaat]

@dlon Any ideas about this? Meanwhile I have tried Windows Network Reset, 2023.1 and 2023.2 but still not fixed.

[dlon]

@Geblaat Try setting the MTU and see if that helps: mullvad tunnel wireguard mtu set 1280. We may have increased the default MTU too much on some networks/machines.

[Geblaat]

@dlon I did, it did not help. It doesn't seem to be protocol specific. I've tried OpenVPN as well and it is also slow. On 2022.2 both Wireguard and OpenVPN are fast.

[dlon]

@Geblaat Thank you for the update. Since we have determined that the issue is not related to MTU or metrics, I don't have any further suggestions at this time. If you find some way to work around it, please get back to me.

[Geblaat]

@dlon No workaround so far but I did narrow the problem down a little more. It doesn't seem to be related to the VPN tunnel itself. I used split tunneling to exclude Firefox from the VPN. Initial loading of websites is then still slow on Firefox. But Firefox is fast again when I disconnect the VPN(No Lockdown mode). I also tried uninstalling security software and disabling all physical and virtual network adapters except ethernet and Mullvads adapter but that didn't help.

[faern]

When you exclude a process from the tunnel its DNS requests still go in the tunnel. So if it indeed is the DNS that is slow, it would be so both in excluded and included mode.

Could you time DNS lookups? If you in a terminal do a few DNS lookups, are they also very slow when Mullvad is connected and fast when disconnected?

nslookup <domain>
# or:
Resolve-DnsName <domain>

[Geblaat]

When you exclude a process from the tunnel its DNS requests still go in the tunnel. So if it indeed is the DNS that is slow, it would be so both in excluded and included mode.

Could you time DNS lookups? If you in a terminal do a few DNS lookups, are they also very slow when Mullvad is connected and fast when disconnected?

nslookup <domain>
# or:
Resolve-DnsName <domain>

If I do DNS lookups in the terminal they are fast when connected as well.