Wireguard VPN setup

[solene]

try reducing the mtu of the wireguard interface

(direct link to the anchor at the top of the topic)

Wireguard VPN setup

Good news, with fedora-38 the network manager supports Wireguard out of the box! The only thing required are extra firewall rules in the VPN qube, as explained in the community documentation about VPN. What you’ll need This guide assumes you are using a VPN service that has wireguard support. For example, ProtonVPN and Mullvad VPN do support it. But you can also follow this guide to add any other (even your own). Create a new qube providing network Make sure fedora-38 t…

[solene]

I just updated the hardening part (I didn’t write it initially) to use nftables.

I tested it on my computer, but having other eyes on it would be appreciated

[apparatus]

OpenVPN should have more overhead than wireguard so I don’t think that’s the problem. But still this could be the problem if there are some specific configurations so it’s worth to be checked.

[Tezeria]

For me, all is ok.
If i shutdown the vpn, no connection. If i start it, good connection with the ip of the vpn provider (ProtonVpn)

[sigma]

@apparatus

And it you don’t redirect all the virtual DNS traffic to the real DNS server (be it 9.9.9.9 or the DNS provided by VPN server) in sys-vpn then you’ll have DNS leak because this virtual DNS traffic will be redirected to sys-vpn’s netvm and downstream.

Do you mean when VPN connection drops or when connected to VPN?

[apparatus]

I correct myself (and I’ve edited the post to clarify):

And it you don’t redirect all the virtual DNS traffic to the real DNS server (be it 9.9.9.9 or the DNS provided by VPN server) in sys-vpn then this virtual DNS traffic will go through VPN to these “virtual” addresses and most probably DNS just won’t work since these addresses will be unreachable through VPN. This “virtual” DNS addresses leak could show VPN provider that you’re using Qubes OS.

[sigma]

I have two MullvadVPN VMs set up - 1 following official Mullvad VPN set up guide with wireguard, and the other following guide by Micah Lee: Using Mullvad VPN in Qubes which uses OpenVPN . There are no iptables and no DNS rules in the latter.
I checked both set ups for DNS leaks on browserleaks.com and dnsleaktest.com as well as on Mullvad website and there are no leaks.
Based on your explanation, how is that possible?
In the guide by Micah Lee we are using NetworkManager, which, If I understand correctly, handles DNS requests for VPNs, is that why I’m not having DNS leaks?

[apparatus]

@sigma

In the guide by Micah Lee we are using NetworkManager, which, If I understand correctly, handles DNS requests for VPNs, is that why I’m not having DNS leaks?

I think this is handled by NetworkManager in the same way as it works for sys-net.
On network interface up the qubes-network.service is started and it gets the DNS servers from VPN and use them for DNAT redirect rules.

[solene]

yes, network manager creates the according rules (certainly with a Qubes OS helper script) when you set the DNS server in the wireguard connection

[solene]

OpenVPN doesn’t have this issue, wireguard has it, it was reported / fixed multiple time in this forum and I’ve been able to reproduce the issue. Maybe it’s because OpenVPN tun device works differently than the WireGuard pseudo device

[apparatus]

Maybe you’re right, need to check the openvpn protocol.

[apparatus]

Seems like there is also internal fragmentation in openvpn protocol and that’s why it works:

–fragment args
Valid syntax:

fragment max fragment max mtu

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

If the mtu parameter is present the max parameter is interpreted to include IP and UDP encapsulation overhead. The mtu parameter is introduced in OpenVPN version 2.6.0.

If the mtu parameter is absent, the max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

The --fragment option only makes sense when you are using the UDP protocol (–proto udp).

–fragment adds 4 bytes of overhead per datagram.

See the --mssfix option below for an important related option to --fragment.

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

Having said that, there are circumstances where using OpenVPN’s internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

[solene]

thanks for checking that!

[webmazter]

under the " Configure your VPN in the Network Manager" section of your guide, I get the following error when I do this:

$ nmcli connection import type wireguard file wg-NL-FREE.conf 
Error: failed to import 'wg-NL-FREE.conf': The name of the WireGuard config must be a valid interface name followed by ".conf".

Do to I put eth0 before the conf file?

[DVM]

Change your file name to something simpler without capital letters.

[webmazter]

Also i’m not sure how wireguard is included in fedora out of the box. I had to manually install mine. I think I might try this with debian instead.

[webmazter]

How will that help?

[DVM]

It’s just an assumption based on the error you got. It says that the wireguard config name must be a valid interface name. Since it uses the filename for the interface it creates, it might fix your problem.

[solene]

What did you install exactly?

[Tezeria]

@webmazter for example, i simply rename the file to “wg-US-132048” and is working for me…