Wireguard + Streisand in StandaloneVM Qubes 4.0

[ghost]

I use following steps to install wireguard on Qubes 4.0:

1- Create a Standalone VM(sys-wireguard) (based on template (fedora-28)) with "provides network"

2- Switch it to HVM mode and kernel="" (HVM mode should allow it to boot) in dom0: qvm-prefs sys-wireguard qvm-prefs sys-wireguard kernel ''

3- Install Wireguard sudo dnf copr enable jdoss/wireguard sudo dnf install wireguard-dkms wireguard-tools

4- Move the client configuration file into the correct directory:

sudo sh -c 'umask 077; mkdir -p /etc/wireguard; cat > /etc/wireguard/card-upgrade.conf' < ~/Downloads/card-upgrade.conf

5 Firewall Anti-leak & DNS Setup

Add the following to /rw/config/qubes-ip-change-hook

!/bin/sh

. /var/run/qubes/qubes-ns vpndns1=10.192.122.1 # <-- The dns of wireguard in /etc/wireguard/card-upgrade.conf iptables -F OUTPUT iptables -I FORWARD -o eth0 -j DROP iptables -I FORWARD -i eth0 -j DROP iptables -F PR-QBS -t nat iptables -A PR-QBS -t nat -d $NS1 -p udp --dport 53 -j DNAT --to $vpndns1 iptables -A PR-QBS -t nat -d $NS1 -p tcp --dport 53 -j DNAT --to $vpndns1 iptables -A PR-QBS -t nat -d $NS2 -p udp --dport 53 -j DNAT --to $vpndns1 iptables -A PR-QBS -t nat -d $NS2 -p tcp --dport 53 -j DNAT --to $vpndns1

...then make it executable with chmod +x sudo chmod +x /rw/config/qubes-ip-change-hook

sudo /rw/config/qubes-ip-change-hook

6- sudo wg-quick up card-upgrade

My Problem is that in the AppVM which its NetVM is sys-wireguard, the loading of some sites like twitter takes too long than usual (about 2 minutes to be completely loaded) and sometimes they aren't loaded at all. some other sites like youtube load very fast and without problem. I don't have such problem when using the AppVM which its NetVM is sys-openvpn (with the same server (streisand)).

---

More info about dns leak: By my own testing, there is no dns leak on wireguard. (I tested both in sys-net and sys-wireguard by using wireshark).

Is there any problem with IPtables rules that wireguard can't load some sites like twitter?

By the way, this wireguard account (card-upgrade) has no problem in ubuntu.

https://github.com/tasket/Qubes-vpn-support/wiki/Wireguard-VPN-connections-in-Qubes-OS https://github.com/tasket/Qubes-vpn-support/issues/10 https://github.com/StreisandEffect/streisand

[tasket]

This is working fine using Debian 9 VM and a Mullvad wg server; no noticeable delays on twitter, youtube, etc.

[ghost]

My problem is with Streisand WireGuard. I tested mullvad[1] iptables rules but didn't work. I also tested on all StandaloneVM based on template (fedora-27 , debian-9) but didn't get any result.

Streisand WireGuard Client Profile for more info:

# "card-upgrade" - Streisand WireGuard Client Profile
[Interface]
Address = 10.192.122.2/32
# The use of DNS below effectively expands to:
#   PostUp = echo nameserver 10.192.122.1 | resolvconf -a tun.%i -m 0 -x
#   PostDown = resolvconf -d tun.%i
# If the use of resolvconf is not desirable, simply remove the DNS line
# and use a variant of the PostUp/PostDown lines above.
# The IP address of the DNS server that is available via the encrypted
# WireGuard interface is 10.192.122.1.
DNS = 10.192.122.1
PrivateKey = ab1CjGhcXeiVqbhV4oclvs/asskH98hlq0cnF+73D=

[Peer]
PublicKey = YVbqfpLmQv5fDp+sI6BVyE12fmHoPKSXe2jiguRbNbb=
AllowedIPs = 0.0.0.0/0
Endpoint = serverip:port 

[1] https://mullvad.net/en/guides/qubes-os-4-and-mullvad-vpn/

[d3adb33f]

I'm having the same issue while on wireguard. Strangely I'm not able to reproduce this while on openvpn. Based on the packet captures, I can see that the TLS handshake for some sites stalls, after the client hello is sent. The connection then hangs until it times out.

Its definitely something in the iptables that is tampering with the traffic from other Appvms. Although I don't know what rule is causing this erratic behavior this happens randomly, sometimes I'm able to connect to the same site without any issues. When the request is originated from the sys-wireguard netvm I don't have any issues whatsoever, everything works as expected, this only happens when the request is routed through the sys-wireguard from an appvm.

Any ideas what might be causing this?

[tasket]

I think this could be due to differing MTU size and the need for packet fragmentation. This post describes a solution where vif (downstream vm) interfaces are set to MTU of 1420 to match wireguard:

https://groups.google.com/d/msgid/qubes-users/e77baa808b600ce67de9a415a4b8330e%40disroot.org