Sys-vpn extremly slow

User Support
1

Hello Community,

I created a sys-vpn Qube a few days ago and I have to say that the speeds are really extremely slow. I for example use Perfect Privacy.

If I set up the sys-vpn Qube as a network provider for another Linux container (e.g. Whonix or Debian), the whole thing still works okaish, but under Windows 10 it’s hell. I have already lowered the MTU, but without success.

Now I wanted to ask, for example, what speaks against simply setting up sys-firewall as NetQube under Windows 10 and installing the Perfect Privacy Client in the Windows 10 VM.

I would also like to know what else I can do to achieve more speed here. For example, I have a download speed of 1.95 Mb/s under Windows 10. In addition, websites or other connections are often not resolved at all.

Thank you very much.

Edith: I followed this tutorial

2

Hi,

What is the speed from the sys-vpn qube itself?

1 Like
3

Hey, thanks for your reply.

Approx 2 Mb/s, almost as low as in the windows vm. Got the same problems in the sys-vpn qube, regarding not resolving websites and stuff.

When I was using the same VPN-Service on my Windows 11 host - before switching to qubes - it was about 80-100 Mb/s in average.

4

So you have 2 Mb/s in sys-vpn itself but in debian qube connected to sys-vpn you have higher speed (80-100 Mb/s?)?

1 Like
5

No, in the sys-vpn qube and in all other qubes, like Debain or Windows 10, which use the sys-vpn as net qube, I have about 2 mb/s speed.

I had the speeds of 80-100 mb/s in my Windows 11 setup before I even switched to Qubes OS. That was just for reference to rule out that the VPN provider itself is that slow.

6

Did you try to use VPN inside the qube (Debian or Windows) without sys-vpn? Was the speed normal?
If you didn’t try it before then try it for a test.

1 Like
7

This time, instead of using fedora as indicated in the tutorial for sys-vpn, I used debian. I simply installed openvpn and established the connection not via the network manager, but directly via openvpn cli and overwrote the entries in /etc/resolv.conf, as the qubes os entries were entered here, which I suspect probably caused some pages in the other setup not to be resolved. with this setup I have between 80 and 130 mb/s, depending on the test platform.

1 Like
8

Can you try the same with wireguard in debian?
I guess that it’s an issue with MTU.

1 Like
9

Unfortunately the provider does not support wireguard yet

10

I assumed that you tried to set up wireguard because the linked guide was about setting up wireguard VPN.
What if you try to use network manager in your debian qube instead of openvpn cli?
What if you try to set up sys-vpn based on debian qube?

1 Like
11

Sadly, I currently cannot get the DNS to run in the setup - if I don’t hard overwrite the resolv.conf - whether in the sys-vpn qube or in a connected appvm qube, and I still can’t figure out why. Maybe you or someone else could help me with this.

This is the sys-vpn configuration:

openvpn-client.ovpn 
auth-user-pass pass.txt
client
dev tun
hand-window 120
inactive 604800
mute-replay-warnings
nobind
persist-key
persist-remote-ip
persist-tun
ping 5
ping-restart 120
redirect-gateway def1
remote-random
reneg-sec 3600
script-security 2
tls-cipher TLS_CHACHA20_POLY1305_SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS_AES_256_GCM_SHA384:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
verb 4

route-delay 2
resolv-retry 60
route-method exe


tun-mtu  1500
tun-mtu-extra  32
mssfix 1450

proto udp



remote 95.168.167.236 44 

remote 95.168.167.236 443 

remote 95.168.167.236 4433 

remote 95.211.95.233 44 

remote 95.211.95.233 443 

remote 95.211.95.233 4433 

remote 95.211.95.244 44 

remote 95.211.95.244 443 

remote 95.211.95.244 4433 

remote 37.48.94.1 44 

remote 37.48.94.1 443 

remote 37.48.94.1 4433 

remote 85.17.64.131 44 

remote 85.17.64.131 443 

remote 85.17.64.131 4433 

remote 85.17.28.145 44 

remote 85.17.28.145 443 

remote 85.17.28.145 4433 



data-ciphers AES-256-GCM
auth SHA512


remote-cert-tls server

<ca>
###removed###
</ca>
<cert>
###removed###
</cert>
<key>
###removed###
</key>
<tls-crypt>
###removed###
</tls-crypt>

up 'qubes-vpn-handler.sh up'
down 'qubes-vpn-handler.sh down'
qubes-vpn-handler.sh 
#!/bin/bash
set -e
export PATH="$PATH:/usr/sbin:/sbin"
  
case "$1" in
  
up)
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
# Format is 'X.X.X.X  Y.Y.Y.Y [...]'
if [[ -z "$vpn_dns" ]] ; then
    # Parses DHCP foreign_option_* vars to automatically set DNS address translation:
    for optionname in ${!foreign_option_*} ; do
        option="${!optionname}"
        unset fops; fops=($option)
        if [ ${fops[1]} == "DNS" ] ; then vpn_dns="$vpn_dns ${fops[2]}" ; fi
    done
fi
  
nft flush chain ip qubes dnat-dns
if [[ -n "$vpn_dns" ]] ; then
    # Set DNS address translation in firewall:
    for addr in $vpn_dns; do
	nft add rule qubes dnat-dns iifname == "vif*" tcp dport 53 dnat "$addr"
        nft add rule qubes dnat-dns iifname == "vif*" udp dport 53 dnat "$addr"
    done
    # echo "setup ips: ${vpn_dns}" > /rw/config/vpn/dns.log
    su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user
else
    su - -c 'notify-send "$(hostname): LINK UP, NO DNS!" --icon=dialog-error' user
fi
  
;;
down)
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user

# Restart the VPN automatically
sleep 5s
sudo /rw/config/rc.local
;;
esac
user@sy
dns.log 
setup ips: 37.48.94.55 185.17.184.3
rc.local 
VPN_CLIENT='openvpn'
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon'

groupadd -rf qvpn ; sleep 2s
sg qvpn -c "$VPN_CLIENT $VPN_OPTIONS"
su - -c 'notify-send "$(hostname): Starting $VPN_CLIENT..." --icon=network-idle' user
output of nft list table ip qubes 
table ip qubes {
	set downstream {
		type ipv4_addr
	}

	set allowed {
		type ifname . ipv4_addr
	}

	chain prerouting {
		type filter hook prerouting priority raw; policy accept;
		iifgroup 2 goto antispoof
		ip saddr @downstream counter packets 0 bytes 0 drop
	}

	chain antispoof {
		iifname . ip saddr @allowed accept
		counter packets 0 bytes 0 drop
	}

	chain postrouting {
		type nat hook postrouting priority srcnat; policy accept;
		oifgroup 2 accept
		oif "lo" accept
		masquerade
	}

	chain input {
		type filter hook input priority filter; policy drop;
		jump custom-input
		ct state invalid counter packets 0 bytes 0 drop
		iifgroup 2 udp dport 68 counter packets 0 bytes 0 drop
		ct state established,related accept
		iifgroup 2 meta l4proto icmp accept
		iif "lo" accept
		iifgroup 2 counter packets 0 bytes 0 reject with icmp host-prohibited
		counter packets 0 bytes 0
	}

	chain forward {
		type filter hook forward priority filter; policy accept;
		jump custom-forward
		ct state invalid counter packets 0 bytes 0 drop
		ct state established,related accept
		oifgroup 2 counter packets 0 bytes 0 drop
	}

	chain custom-input {
	}

	chain custom-forward {
		iifname "eth0" counter packets 0 bytes 0 drop
		oifname "eth0" counter packets 0 bytes 0 drop
	}

	chain output {
		type filter hook output priority filter; policy accept;
		oifname "eth0" meta skgid 992 accept
		oifname "eth0" counter packets 0 bytes 0 drop
	}

	chain dnat-dns {
		type nat hook prerouting priority dstnat; policy accept;
		iifname "vif*" tcp dport 53 dnat to 37.48.94.55
		iifname "vif*" udp dport 53 dnat to 37.48.94.55
		iifname "vif*" tcp dport 53 dnat to 185.17.184.3
		iifname "vif*" udp dport 53 dnat to 185.17.184.3
	}
}
/etc/resolv.conf 
nameserver 10.139.1.1
nameserver 10.139.1.2

What am I missing here? Why are the DNS queries not being made correctly? The resolution does not work, not even via ping. So this means the local DNS resolution is already not working.

For example:

user@sys-vpn-pp-amsterdam:/rw/config/vpn$ ping google.com
ping: google.com: Name or service not known

I followed these instructions: Configuring a ProxyVM VPN Gateway

Very much thanks!

12

Try to ping google.com from qube connected to sys-vpn-pp-amsterdam.

Did you try to use the same DNS that you have in dnat - 37.48.94.55?
If you set 37.48.94.55 in /etc/resolv.conf in sys-vpn-pp-amsterdam then DNS will work in qubes connected to sys-vpn-pp-amsterdam?
Setting DNS in /etc/resolv.conf in qubes connected to sys-vpn-pp-amsterdam won’t make a difference since it’ll be DNATed in sys-vpn-pp-amsterdam anyway.

1 Like
13 
user@work:~$ ping google.com
PING google.com (142.251.36.14) 56(84) bytes of data.
From 10.255.240.68 (10.255.240.68) icmp_seq=1 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=2 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=3 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=5 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=6 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=8 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=9 Destination Host Unreachable
From 10.255.240.68 (10.255.240.68) icmp_seq=10 Destination Host Unreachable
^C
--- google.com ping statistics ---
12 packets transmitted, 0 received, +8 errors, 100% packet loss, time 11293ms
pipe 3

Yes, as soon as I change that, I can ping other websites (not google, since its cached i guess - did not flush the cache yet)

user@sys-vpn-pp-amsterdam:/rw/config/vpn$ ping msn.com
PING msn.com (204.79.197.219) 56(84) bytes of data.
64 bytes from 204.79.197.219 (204.79.197.219): icmp_seq=1 ttl=115 time=52.7 ms
64 bytes from 204.79.197.219 (204.79.197.219): icmp_seq=2 ttl=115 time=49.4 ms
^C
--- msn.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 49.381/51.054/52.728/1.673 ms
14

DNS seems to be working in the qube connected to sys-vpn-pp-amsterdam but there is some issue with routing or firewall.
What if you ping IP address in work qube?

ping 8.8.8.8
1 Like
15

With default settings in sys-vpn-pp-amsterdam resolv.conf(10.139.1.1 10.139.1.2):

user@work:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.255.240.68 icmp_seq=1 Destination Host Unreachable
From 10.255.240.68 icmp_seq=2 Destination Host Unreachable
From 10.255.240.68 icmp_seq=4 Destination Host Unreachable
From 10.255.240.68 icmp_seq=8 Destination Host Unreachable
From 10.255.240.68 icmp_seq=9 Destination Host Unreachable
From 10.255.240.68 icmp_seq=11 Destination Host Unreachable

With changed settings in sys-vpn-pp-amsterdam resolv.conf(37.48.94.55 185.17.184.3):

user@work:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.255.240.68 icmp_seq=1 Destination Host Unreachable
From 10.255.240.68 icmp_seq=2 Destination Host Unreachable
From 10.255.240.68 icmp_seq=3 Destination Host Unreachable

Tried other pages with changed config, and some of them are working. Maybe 8.8.8.8 was cached, because I tried this already before.

Again with default settings:

user@work:~$ ping nyc.com
PING nyc.com (172.66.41.36) 56(84) bytes of data.
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=1 ttl=247 time=24.9 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=2 ttl=247 time=25.9 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=3 ttl=247 time=26.9 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=4 ttl=247 time=44.4 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=5 ttl=247 time=27.6 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=6 ttl=247 time=28.3 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=7 ttl=247 time=25.9 ms
64 bytes from 172.66.41.36 (172.66.41.36): icmp_seq=8 ttl=247 time=32.5 ms
^C
--- nyc.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 24.925/29.543/44.387/6.010 ms
user@work:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.255.240.68 icmp_seq=1 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 0 received, +1 errors, 100% packet loss, time 5140ms
pipe 3
user@work:~$ ping weather.com
PING weather.com (23.197.146.246) 56(84) bytes of data.
64 bytes from a23-197-146-246.deploy.static.akamaitechnologies.com (23.197.146.246): icmp_seq=2 ttl=51 time=323 ms
64 bytes from a23-197-146-246.deploy.static.akamaitechnologies.com (23.197.146.246): icmp_seq=3 ttl=51 time=325 ms
64 bytes from a23-197-146-246.deploy.static.akamaitechnologies.com (23.197.146.246): icmp_seq=4 ttl=51 time=333 ms
64 bytes from a23-197-146-246.deploy.static.akamaitechnologies.com (23.197.146.246): icmp_seq=5 ttl=51 time=332 ms
^C
--- weather.com ping statistics ---
6 packets transmitted, 4 received, 33.3333% packet loss, time 5184ms
rtt min/avg/max/mdev = 322.876/328.307/333.168/4.463 ms
user@work:~$ ping whatsmyip.com
PING whatsmyip.com (188.114.97.3) 56(84) bytes of data.
64 bytes from 188.114.97.3 (188.114.97.3): icmp_seq=1 ttl=55 time=48.4 ms
64 bytes from 188.114.97.3 (188.114.97.3): icmp_seq=2 ttl=55 time=48.8 ms
^C
--- whatsmyip.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 48.377/48.613/48.849/0.236 ms

Hopefully I did not fuck up any tests since I did not restart anything when switching entries in resolv.conf
I tried a few more in firefox on work qube, and they did not resolve. Like 1 page did - maybe cached - google and a few others didnt.

I tested ping again with default settings in sys-vpn-… still not possible:

user@sys-vpn-pp-amsterdam:/rw/config/vpn$ ping facebook.com
ping: facebook.com: Name or service not known
16

Maybe it’s an MTU issue.
Run this command in sys-vpn-pp-amsterdam:

nft add rule ip qubes custom-forward tcp flags syn / syn,rst tcp option maxseg size set rt mtu

And try to ping and check the browser of work qube.

1 Like
17

With which settings? The default resolv.conf (10.139.1.1 10.139.1.2) or the one with changed nameservers?

18

With default resolv.conf.

1 Like
19

It’s much better now. I tried 10 websites and I was able to open 8 of them. Also speedtest is around 300 mb/s now. Although ping within the sys-vpn-… qubes still does not work.

Thank you very much!

One more question: Did I miss something regarding a reliable killswitch and leak protection? Does it make sense to add firewall rules in sys-vpn-… settings to only access to the remote IPs of the VPN servers?

20

Killswitch inside the qube is configured correctly.

Yes, it makes sense to configure qubes firewall as well in case when your sys-vpn will get compromised and it could disable in-vm killswitch.

1 Like