I am very, very close… I think I will try a Qubes-OS reinstall, before I bust down to Flatland.
I have that running on other Qubes, anyway.
wait… set up Mullvad in the AppVM?? If it counts, I have tried Firefox in the ProxyVM, (several of them), and it shows the same behaviour - most sites not loading but some, e.g. redcross.org, download, albeit slowly.
I’ve also made a “dummy” ProxyVM (i.e. providing network to an AppVM but no vpn set up) - the AppVM works just fine.
Its been six days. I think I am just going to reinstall (although that wasn’t without problems last time, either).
in that case @disp6252 is most likely right (he was from the beginning) - it definitely looks like an mtu problem. Try the ip link command he suggested. You could also try the following:
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420
Set the MTU in the AppVM as instructed, but no change.
Worth noting that Mullvad’s instructions to make the ProxyVM tell you to use qvm-firewall commands to “drop” icmp, i.e. qvm-firewall vpn-au-wg-nyc add --before 3 drop proto=icmp
But also worth noting that Mullvad support have no idea what’s happening here (they say my problem is “not normal”). I don’t think this has happened to any other instance, so their protocol must normally work (and indeed it did for me until recently).
Try to remove the icmp drop rule in firewall for a test.
If the change in link mtu didn’t have any effect than maybe the problem is somewhere else but I’m not sure where.
Got an email from Mullvad support, and found a mistake I’d been making with curl (note the http/s):
[user@vpn-us-nyc-wg-301 ~]$ curl https://am.i.mullvad.net/connected
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to am.i.mullvad.net:443
[user@vpn-us-nyc-wg-301 ~]$ curl http://am.i.mullvad.net/connected
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
So, am.i.mullvad.net/connected is defunct. It fails completely on https, so every time I have tried to curl I have failed.
In contrast, Mullvad’s instructions:
Instead of using sys-mullvad try to install mullvad app in test appvm (in setup sys-net → sys-firewall → test-appvm) and check if the firefox will work in this test appvm with VPN from mullvad app.
Done that. Its a Standalone Debian VM. Everything works fine in Firefox in that ‘testVM’. Visiting mullvad.net shows I’m connected to their server (using their little banner at the top of the page).
However, it won’t act as a ProxyVM for any other VMs.
First, my ProxyVMs using Mia Leah’s protocol, failed. Same as this, they just stopped working (I don’t think I tested if they loaded redcross.org, but nothing else worked).
I tried Mullvad’s instructions (twice or more) for OpenVPN ProxyVM, and they failed.
At some point, I reinstalled Qubes OS. That’s this incarncation.
I tried Mullvad’s OpenVPN protocol (several times) → fail
I tried Mullvad’s Wireguard (several times) → it worked for three weeks, then fail.
Whatever mistake I’ve possibly made, I must’ve done it consistently - and even that doesn’t make sense because things have worked, at times.
I don’t think another protocol will offer anything, although I’ll take a look at tasket’s Wireguard instructions.
I think I tried tasket’s config (OpenVPN), and it too failed.
[user@sys-net ~]$ ip a | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: ens6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
3: wls7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
4: vif6.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 32
[user@sys-net ~]$ curl https://browserleaks.com/ip | grep MTU
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 <tr><td>MTU</td><td>1280</td></tr>
100 14796 0 14796 0 0 10593 0 --:--:-- 0:00:01 --:--:-- 10598
But ping just hangs:
[user@sys-net ~]$ ping 9.9.9.9 -s 1472 -M do
PING 9.9.9.9 (9.9.9.9) 1472(1500) bytes of data.
Do you have the ICMP disabled in your router to which you’re connected?
Do you have VPN configured on this router?
Seems like the MTU is restricted to 1280 somewhere down the link.
Try to lower the MSS value in ping command to find out which value will work. ping 9.9.9.9 -s 1252 -M do
1252 works. In fact, I’ve just tested it and it will ping all the way to 1444 in sys-Net. I’ve tried to map all along the network chain using this ping command:
sys-Firewall: 1444 maximum
ProxyVM: 1380 maximum
AppVM, 1380 maximum.
(Yes, definitely 1380 not 1280). I don’t understand this.
I use an Android cellphone as a hotspot, so that’s my router. Its interesting, because I had used a different phone with a different network provider for about 4 weeks - changing back to my usual phone was around about the same time as this problem cropped up.
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?
But why don’t Whonix and clearnet AppVMs have a problem, then?
Thanks @IceCream , but I have had several setups now, both with multiple and single servers. Don’t think I could face going through another setup just now.