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.
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.
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.
1 Like
I can only guess that your current mobile ISP is using some tunnel that has overhead which your old ISP didn’t have.
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.
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.
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).
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.
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.
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
Happened now to me 2 days in row… Same thing! Fucking annoying to say at least
On vpn vm command “curl am.i.connected…” works, says connected
On vpn vm wireguard gives handshake…
But then the vpn vm wont provide network for other qubes. This stops providing after restart. I have to configure all again and again, somehow now 1 vpn vm “survived” and still provides network normally after the restart.
What was your cure for this?
Have to reach back into my memory banks here, but there were 2 things that stand out to me:
-
The MTU had to be reset, but in the right qube. There was something counterintuitive about it, so keep trying - see above, I had a lot of help and its recorded
-
Completely given up on using OpenVPN Mullvad. Re-did those Mullvad site 's instructions about a dozen times, and it NEVER worked again. No idea why. (Mullvad support wasn’t so good on this, IIRC.) The wireguard set up, on the other hand, does work.
Don’t know why it happened, feel a little uncomfortable that it ‘just happened’, but got my work around. My threat model isn’t so high, (e.g. no state actors coming at me), so I just got on with things.
That’s as much as I can tell you.
Good luck.
1 Like
found my notes. I have to use this command:
-
sudo ip link set dev eth0 mtu 1380 -
has to be set in
/rw/config/rc/local
But I’m not sure that’s entirely correct. I remember that counterintuitive thing (for me, anyway), was about which VM I set it in. So consider:
When I check my proxyVM /rw/config/rc/local, it has the this:
#!/bin/sh
# This script will be executed at every VM startup, you can place your own
# custom commands here. This includes overriding some configuration in /etc,
# starting services etc.
# Example for overriding the whole CUPS configuration:
# rm -rf /etc/cups
# ln -s /rw/config/cups /etc/cups
# systemctl --no-block restart cups
wg-quick up /home/user/[YOUR MULLVAD WG SERVER].conf
# https://forum.qubes-os.org/t/mullvad-proxy-vms-suddenly-stop-working-except-for-mozilla-org-redcross-org-and-wikipedia-org/18668/14
iptables -t nat -I POSTROUTING 3 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
But in my AppVM /rw/config/rc/local, it has this:
#!/bin/sh
# This script will be executed at every VM startup, you can place your own
# custom commands here. This includes overriding some configuration in /etc,
# starting services etc.
# Example for overriding the whole CUPS configuration:
# rm -rf /etc/cups
# ln -s /rw/config/cups /etc/cups
# systemctl --no-block restart cups
# Set MTU to 1380 to work with Mullvad VPN
sudo ip link set eth0 mtu 1380
So it looks like you have to set the MTU in the AppVM.
It took me a while to figure that out - particularly working out exactly what MTU value to use, YMMV - hope it saves you some time. (But as I say, my computer knowledge is limited).
You could also do this method as explained into this section Wireguard VPN setup (some websites aren’t working)
nft add rule ip qubes custom-forward tcp flags syn / syn,rst tcp option maxseg size set rt mtu
cd ..
cd ..
cd rw
cd config
sudo nano rc.local
can someone share working mullvad setup on qubes 4.2 i’m having to re-install mullvad all the time every bootup which makes me sick
you should learn how to proplerly use Qubes OS to be more productive. I guess you are install mullvad in a dispoable VM, you should do it in a standalone VM for a simple setup.
Yes, simple is something that sounds good but in this case it seems not so simple.
I have tried both install mullvad vpn on a AppVM, Standalone VM (both not disposable). I had mullvad running great no problems for 3 months straight on app vm. However the mullvad expired and I had to install it on a new app vm but that where the problems began and haven’t let me live my life normally ever since. This had forced me to bang my head against my keyboard to install mullvad again, again and again!
The problem now is, the mullvad App VM doesn’t provide internet to any qubes after restart. And I wonder why is it like this, because for 3 months all went great I didn’t touch anything
and the odd thing is, I have to “hope” the mullvad qube “survives” the restart and shows that it can provide after restart. if it provides network after restart, then I’ll be good. But if it doesn’t I have to install it on a new qube and again “Hope” it survives.
This is the thing I shouldn’t be hoping something to work and why does it sometimes work, sometimes not doesn’t make sense
If you are looking for a simple solution, I have packaged Mullvad to
provide a Mullvad proxy, as well as disposables. The proxy comes with
the Mullvad GUI for VPN selection. The disposables have the GUI and
Mullvad Browser - you can use the browser without the Mullvad VPN if you
want, or have the disposables running their own VPN.
Look at https://qubes.3isec.org/tasks.html
1 Like
hello the problem was solved using newer fedora template version which had to be updated from 38 → 39.