Mullvad Proxy-VMs suddenly stop working (except for mozilla.org, redcross.org and wikipedia.org)

[IceCream]

on the wireguard set-up you last had working, have you tried to only have one server going through and the others commented #? Mullvad about 3-4 weeks did require new wireguard configs for some servers,. So if you had one of those, a completely new setup would be required. .Dont think your issue is related to MTU.

[disp6252]

@tree

So does this mean that the cellphone (or provider) has introduced an MTU bottleneck of 1444 (bytes?), and I need to throttle my [AppVM-ProxyVM-FirewallVM-NetVM] setup to 1444 1380 or less?

Try to set the MTU in AppVM and check if firefox will work:
sudo ip link set dev eth0 mtu 1380

@tree

But why don’t Whonix and clearnet AppVMs have a problem, then?

Hard to answer for sure, maybe MTU 1444 is causing less problems than 1380 with VPN and you just don’t notice them.

[tree]

They were single servers, two different ones, and no messages about them were on the website. Besides, I have have another (yet another server, )and still getting the same problems.

[IceCream]

Probably an issue with the servers, If you have used WireGuard on Qubes OS - Guides | Mullvad VPN you often have to change server manually in rc.local by uncommenting and commenting. While their website doesnt show any issues, there apparently are.

[tree]

@disp6252

Try to set the MTU in AppVM and check if firefox will work:
sudo ip link set dev eth0 mtu 1380

IT WORKED!! Doing backflips here!

Still have questions, though. Why/how did it happen, especially all of a sudden? Will it affect OpenVPN setups, too (which also refused to work)? Will it happen again? And why did sites like redcross.org and wikipedia.org load - do they ‘demand’ less MTU than .com sites?

Thankyou very much for your persistent help, @disp6252 . Much appreciated.

[disp6252]

@tree

Why/how did it happen, especially all of a sudden?

I can only guess that your current mobile ISP is using some tunnel that has overhead which your old ISP didn’t have.

@tree

Will it affect OpenVPN setups, too (which also refused to work)?

Yes, but if OpenVPN will use tcp then you’ll have to lower MTU some more.
UDP has fixed 8 byte header and tcp has variable header size from 20 bytes minimum to 60 bytes maximum.

@tree

And why did sites like redcross.org and wikipedia.org load - do they ‘demand’ less MTU than .com sites?

Some sites may restrict the MTU size on their end, so browser will use lower MTU value that was requested by this site. But it’s a guess.

[disp6252]

Maybe you can try to set MTU to 1380 in wireguard config and you AppVM will automatically adjust its MTU using ICMP (if ICMP isn’t blocked between AppVM and ProxyVM).

[tree]

I think I will just stick to the ip link... command. I remember I tried setting MTU = 1280 in a conf file, and it didn’t do anything.

[tree]

@disp6252

Yes, but if OpenVPN will use tcp then you’ll have to lower MTU some more.
UDP has fixed 8 byte header and tcp has variable header size from 20 bytes minimum to 60 bytes maximum.

I had an OpenVPN proxyVM set up in a standalone qube (standalone as per Mullvad’s instructions)- changing the AppVM MTU to 1380 worked on that, too. In the next 24 hours, I will set up another OpenVPN proxy, but I expect the same behavior.

[tree]

For the record:

The command to reset MTU does not survive reboots. (Includes in templates).

Instead, save

sudo ip link set dev eth0 mtu 1380

as a line in /rw/config/rc.local