Wireguard VPN setup

Community Guides
12

Somehow I had missed your feedback.

Good point. Thanks for catching that. Just fixed it.

I didn’t find a way to add a pre-existing config via the NetworkManager GUI. As far as I found, we can only import OpenVPN config files. Is there an option for import wireguard config files directly? If so, I’d love to have it there because having a 100% GUI guide is perfect.

Sorry, I don’t fully understand what you mean, but feel free to change whatever. It’s your guide after all :slight_smile:

13
  • click on nm-applet
  • select “VPN Connections” → “Configure VPN…”
  • click on +
  • Select “Import a saved VPN configuration…”

It worked for me with a wg-quick configuration file

14

It didn’t work for me, unfortunately :pensive:

didntwork
didntwork699×234 14.6 KB

My config file looks something like this: (IPs / keys replaced)

[Interface]
PrivateKey = ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Address = X.X.X.X/32,YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY/128
DNS = X.X.X.X

[Peer]
PublicKey = KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = Q.Q.Q.Q:51820

In your setup that worked is it something like that?

15

Interesting, I can’t remember my file and I don’t have it anymore.

Maybe an extra package is required? (like wg quick maybe)

16

I just installed wireguard-tools, which provides wg-quick but that didn’t fix it, sadly.

17

We are not the first ones navigating on these waters apparently:

18

Supposedly the code supports it:

19

After some more digging, it turns out that it’s not yet available. On fedora-38 we have network-manager-applet version 1.30.0 and we need at least 1.32.0. So this will probably only be possible on Fedora 39 :confused: Not even if we switch to debian 12…

20

Great write up, thanks! I’m using this method in 4.2 Fedora 38 as it seems the 4.1 method published (officially by Mullvad) doesn’t work. I think SELinux is preventing execution/autostart of Wireguard in /rw/config/rc.local.

This network manager method auto starts, so all is good!

One thing I like to do from that guide, is the optional advice to disable non-tunnelled pinging - from the Mullvad guide:

Disable ping (optional)

As noted in the qube Firewall rules window, those rules do not apply to DNS requests and ICMP (pings). If you want to block pings too then you can use the qvm-firewall command.

  1. Click on the Qubes app menu and open Terminal Emulator.
  2. Run qvm-firewall MullvadVPN list. Find the rule in the bottom that says “accept icmp” and note the line number.
  3. Run qvm-firewall MullvadVPN del --rule-no NUMBER. Replace NUMBER with the line number you found above.
  4. Run qvm-firewall MullvadVPN add --before NUMBER drop proto=icmp. Replace NUMBER with the line number you found above. This new rule will be added before the last “drop” line.
  5. Check it by running the list command again. The rules should be in this order: accept (the IP addresses of the VPN servers), accept dns, drop icmp, drop.
1 Like
21

Solene. a thousand aplogies. I messed up your first post.

I did not realize my priviliges including editing someone else’s post. so I did not intend to change anything you had written.

Someone should take the permission off my account.

I was intending to keep a small record of what instructions i thought might be changed to be more clear as I am going through process.

Again apologies.

Does Mullvad supply a list of terminal commands that show which VPN nodes have the most traffic - best speed available nodes.

And commands to issue to change to the more useful, available nodes.

Again I apologize.

22

It’s ok to make mistakes, just make sure to learn from it, and clean the mess :slight_smile:

Because you made a mistake? This is ridiculous. People make mistakes, you can’t make mistakes if you don’t have the opportunity, but if you make mistakes, you learn, you get experiences, and you can do better next time, and teach people how to not make the same mistakes as you.

Except if you don’t want to edit documentation anymore, in which case it would make sense.

I can see the history of changes on the topic, it seems some changes don’t make sense, like the addition of

Maybe instead of show up

will be available to be started from
upper left Q / Services.
``

is it what you are apologizing for?
23

Yes. That is what I added.
Sorry I could not re edit it. I guess someone realized I should not have been allowed to edit and removed my permission.

I had already created a sys-mullvad Qube and tried to install the Mullvad GUI app. Which caused me to have a different response than what your documentation shows.

I am not sure if I might have deleted something.

Sorry. Again.

I will endeavor to not do such again.

2 Likes
24

fixed :ok_hand:

25

In the community guides section we aim to have things as editable wikis. So anyone can edit and contribute. If someone messes something up (either on purpose or by mistake) we can always revert that :slight_smile:

So no problem. We learn by mistake as @solene is saying.

2 Likes
26

Hello Solene, thank you for this amazing guide it’s working flawlessly for me. Just a few questions.

Has there been any extensive (or nonextensive) leak tests done to make sure that these iptables rules are sufficient enough to prevent a vpn leak? Of course using the Qubes GUI to set the firewall to the VPN end point is one way to do this however, it would be nice if the vpn setup was leakproof without relying on the Qubes Firewall. I am a user that always sets the Qubes Firewall to limit outgoing connections to the wireguard vpn end point, however in a case such as a bug in the firewall, I would feel much safer if the iptables rules and network manager would also fail safe by default. Two layers of protection rather than one sort of thing… Also network manager does not fail safe by default which is why I want to make sure that these iptables rules are sufficient enough. Perhaps there is additional hardening that could be done that hasn’t been mentioned in this guide? Or many other users who have tried this vpn setup and are coming across my comment have some insight?

Also I am interested to know if you or anybody else will carry this guide onto Qubes 4.2 where we will be moving to nftables by default. (I am hoping you will do so) :slight_smile:

Again, thank you so much for this guide. It’s working very well, just wanted to discuss the aspects of failsafe regarding this setup.

1 Like
27

No tests were done. I don’t have a high requirment for my personal use and I’m writing this on my free time :slight_smile:

28

Regarding leaks, I haven’t done extensive testing either. It may leak ICMP packets (pings) if the advanced part is skipped. This is because the Qubes GUI firewall by default leaks those.

It would be nice to have it updated indeed. We also welcome contributions by anyone. So if you get it working, feel free to improve it.

Starting in Fedora 29 39 networkmanager-applet will have the ability to add wireguard connections via the UI. So the guide may be updated too to remove the command line for that

1 Like
29

you meant 39 right? :slight_smile:

1 Like
30

confirming that guide works with 4.1.2 will test soon on RC

2 Likes
31

Run into some weird errors probably due to my lack of understanding though i think the guide should mention a few more things + be made into an ASCI text file to make a offline copy easy.

  1. There is the need to hvm the new sys-vpn.
  2. and then add the network adapter, ethernet port or wifi adapter internal or external to the sys-vpn
  3. follow the guide
  4. once this is done you can only set firewall rules in the firewall

Please correct me if i am wrong but this is the ony way i could get it to run while traveling with a notebook and random wifi hotspots.