Why QubesOS need some control over OpenVPN set ups? while other VPNs can work from the box? what is the sense of it?

General Discussion
1

TLDR: I already read infinite amount of openvpn’s set up topics at this forum and in the internet. Main question: Why QubesOS need some control over OpenVPN set ups? while other VPNs can work from the box? what is the sense of it?

I already had proxy qubes with MozillaVPN and ExpressVPN installed. It was very straightforward and worked well.
Now I am in country where my standard VPNs are effectively blocked or I have unstable connection. So I decided to use AmneziaVPN set up from some advice and curiosity. I didn’t have OpenVPN experience before not in the Qubes nor in any other OS.
Amnezia was pretty buggy on Linux so after I finally reach step of connecting to OpenVPN server I decided that it was Amnezia problem. After a day I tried to connect directly with OpenVPN client but I had exact same problems. Then I tried (1) official containers, (2) official AWS amis, (3) route through ExpressVPN proxy and Whonix, (4) mixed everything. It never worked.
So finally I tried it from android … and it immediately worked.
Then I started to notice that there are too many OpenVPN topics on the forum and different solutions. Then I installed unman’s sys-vpn task through qubes-task . And tried smt else. But at that moment I was already sick of that.

My question is: Why QubesOS need some control over OpenVPN set ups? while other VPNs can work from the box? what is the sense of it?

2

There is nothing special about OpenVPN compared to other VPNs. It might just be the most widely used one and hence there are the most posts about it.

There are different ways how one can apply a VPN in Qubes OS:

  1. within an AppVM (so only the traffic of that qube/VM uses the VPN)
  2. using a ProxyVM that becomes the NetVM for every AppVM that wants to use the VPN
  3. directly in the sys-net (for everything)

Within an AppVM makes sense if e.g. the qube runs Windows and the VPN is provided by your employer and only has a Windows client. Or maybe it’s a special use case and you know for sure you only need that VPN connection in that one qube.

Installing a VPN in sys-net is in my opinion always a bad idea, since sys-net is untrusted and you also lack the ability to use the firewall the way you do with the ProxyVM/AppVM approach. By that I mean that you want to restrict the qube to only be able to connect to the VPN servers and nothing else, preventing accidental leakage of packets.

So by far the most used approach is to have the VPN reside in a ProxyVM. This is where many contributors have proposed solutions on how to achieve “always connected”, leak proof, low memory usage etc. I share your frustration with most of these solutions. However there is one way that doesn’t require anything special: use a ProxyVM with Network Manager installed including VPN support. In that case you:

  1. import the .ovpn file and have network manager setup the connection / test it
  2. copy a tiny script that you can understand easily yourself to make sure the VPN stays connected
  3. lock down the ProxyVM’s firewall to only allow connections to that VPN server an nothing else

This approach is described in detail here and shouldn’t take you more than 5 minutes to setup. It’s written as a tutorial to setup Mullvad VPN but it will work with any OpenVPN provider that gives you an .ovpn configuration file.

1 Like
3

Thank you for your response!

Exactly!

I want to use OpenVPN connection in proxy mode but in the same way as I used other VPN clients (MozillaVPN and ExpressVPN)

  1. Create AppVM and check “Provides network access to other qubes”
  2. Install openvpn client
  3. Copy “config.ovpn”
  4. “openvpn --config client.ovpn”
  5. Ready!

Why it’s not like this?
Why we need network-manager? and all these set up steps?

How openvpn based vpns are different from other? Why QubesOS block the connection from openvpn client?

I would like to know ideas beyond this.

4

It’s exactly like this. The other steps are for automatic connection and leak prevention. If you don’t care about these, then don’t bother.

That’s not Qubes OS specific. It’s just one of the ways you can use VPNs in Linux. It gives you a nice GUI instead of command line, a tray indicator if you are connected or not and the other steps mentioned are again for automatic connection / re-connection in case of drop and making sure no other traffic can flow through the ProxyVM.

I really don’t see how they are. And Qubes OS doesn’t care at all if and which VPN you use.

Please tell us exactly what you did and what happened. Have you tried the very easy steps I linked to in my previous post?

1 Like
5

Thank you for the patience!

I had thought that it was dns related and tried many akward things.

Finally I did what I had supposed to do first. I edited /etc/resolf.conf to other DNS resolver and it worked!

It worked on proxy qube but I also have to edit it on every destination qube.

Initial value was 10.139.1.1. Would you know why it works with other vpns maybe and failed with openvpn?

Thank you!

6

I encountered an issue where the connection doesn’t work with mirage-firewall. However, when I connect directly to sys-net, it functions correctly.

Additionally, I’ve found that I must manually set the DNS server to 1.1.1.1 (or another address) in the resolv.conf file on the virtual machine I wish to use. If I don’t do this, nothing works.

Through this experience, I’ve learned that QubesOS indeed employs some unique DNS management strategies, which confirmed something I had suspected.

Now, I find myself in a country where popular VPN services are blocked. As a result, I’ve had to set up my own OpenVPN configuration. My current setup is as follows:

sys-net ← openvpn ← othervpn ← firefoxvm (with resolv.conf set to 1.1.1.1)

However, this configuration doesn’t work with the default nameservers set by Qubes, specifically:

nameserver 10.139.1.1
nameserver 10.139.1.2

I believe these addresses are automatically set by Qubes, and they are causing the issue.

7

Hi, to my understanding, 10.139.1.* are used by Qubes to forward dns requests to the last netvm, and this VM use its own dns configuration (resolv.conf) to resolve the DNS request.
It should work with mirage-fw as well as with sys-firewall (at least on my laptop), I’ve managed to get sys-net using a mirage-dns unikernel to resolve the request and forward back to the original AppVM.
I never used openvpn, but I have the following configuration : sys-net ← mirage-fw ← sys-vpn ← AppVM with both openconnect or openfortivpn as client.
Would you mind to describe what is not working with mirage-fw ?

1 Like
8

This has come up a number of times.

Qubes using a rather elegant way of handling DNS, which allows you to
reconfigure networking on the fly.
Each Qube uses the 10.139.1.x addresses for DNS - each qube providing
network forwards traffic to those addresses up to the netvm. At sys-net,
traffic to the 10.139.1.X addresses is subject to NAT to the resolvers
of sys-net.

Instead of manually configuring the DNS in the qube, you should alter
the nftables rules in the netvm.
By default the rules are in the nat table in the PR-QBS chain:

	chain PR-QBS {
		meta l4proto udp ip daddr 10.139.1.1 udp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.1
		meta l4proto tcp ip daddr 10.139.1.1 tcp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.1
		meta l4proto udp ip daddr 10.139.1.2 udp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.2
		meta l4proto tcp ip daddr 10.139.1.2 tcp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.2
	}

You should over ride this in the VPN qube to dnat traffic to the DNS
server provided by the VPN.
You can do this with rules in /rw/config/qubes-firewall-user-script.

If you need help with this, ask.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like