My VPN setup re-explained

This is a side-topic that started in this thread with @newbie.

This is all more or less based on an excellent blog post by Micah Lee.

I’ll try to explain again with more detail:

  1. sys-net is a HW VM that “has” the PCI devices needed to connect to
    networks (i.e. Ethernet, WiFi). In my case this VM is also disposable.

  2. sys-clearnet is a proxy qube that has sys-net as a netvm (get’s its
    connection from sys-net) and functions as a firewall. What that means
    is: it will enforce the firewall settings of qubes connected to it.

  3. sys-njalla is also a proxy qube getting it’s conenction from
    sys-clearnet. It is the one connecting to the VPN . In the firewall
    rules for this qube I specified the IP addresses and port of the VPN
    servers. This means that sys-clearnet enforces that sys-njalla cannot
    contact any other servers then the VPN servers. This is to make sure
    that every qube that uses sys-njalla as netvm only gets a connection
    when sys-njalla is actually connected to the VPN.

  4. sys-vpn is another firewall proxy qube that all other qubes connect
    to. It doesn’t implement VPN but it gets its connection from sys-njalla
    which does implement the VPN. I just called it this way to distinguish
    easily between clearnet and VPN based connections. So if you want your
    app qube to use ‘clearnet’ you connect to sys-clearnet and if you want a
    ‘VPN’ connection you connect to sys-vpn. sys-vpn enforces the firewall
    rules configured for the app qubes.

So: if sys-njalla is the only qube connected to sys-clearnet, then
sys-clearnet and sys-net will only ever see encrypted traffic to/from
Njalla’s VPN servers. Traffic that get’s blocked by sys-vpn will never
even reach sys-njalla and therefore never reach the VPN servers.


What is the point of sys-clearnet and sys-vpn? For example, my vpn proxy appears able to apply firewall rules directly to upstream VMs, with no special setup.

@airelemental asked:

What is the point of sys-clearnet

sys-clearnet has the exact same role as any sys-firewall in a standard
install: it’s purpose is to separate the enforcement of firewall rules
from the sys-net qube which hosts the hardware is is completely untrusted.

Also: maybe you have a tethered phone on sys-usb or an USB-Ethernet
dongle. You can switch networks easily by changing sys-clearnet’s netvm
property to e.g. sys-usb

… and sys-vpn?

As I explained in previous posts I have multiple VPN providers:
sys-njalla, sys-ivpn and also sys-mullvad. If I would connect my app
qubes directly to them I would need to touch the netvm property of every
single app qube to change the provider.

In my setup all app qubes are connected to sys-vpn and so I can simply
switch the VPN provider by touching the netvm property of sys-vpn only.
A major convenience.

In addition my sys-vpn runs apt-cacher-ng and is set as updatevm and
clockvm … so all of those functions go through the selected VPN
provider too.

1 Like

I have many different sys-vpn-[insert-country] configurations so I don’t need to start a software from a provider or care about leaks. I have a sys-net-wlan/sys-firewall-wlan which connects to clearnet for a few selected apps like banking or one for my ISP’s router.

1 Like

i see, so you have 2 sys-firewall,

the 1st firewall, is to ensure,
that sys-njalla vpn, only pointing to one IP, which is VPN server,
and nothing else.

the 2nd firewall, is to block traffic, from some suspicious IP addresses.

okay, understand, thanks

so, since there is sys-clearnet, the firewall to ensure,
that encrypted traffic from sys-njalla, only go to 1 IP address,

do you suspect that maybe, there is secret hidden traffic, from sys-njalla,
that is not detected and encrypted by vpn ?


The motivation is to make sure that no traffic is allowed when there is
no VPN connection.

Because @Sven wanted to discuss firewall’s and VPNs I thought I’d chime in my 0.2 XMR.

I use Cryptostorm VPN ( with a router sort of loosely based on DD-WRT. To find out more check out (

I’m not intentionally shilling the above. I have many reasons which I won’t go into for my choices. Previously I use the awesome @tasket for my OpenVPN needs

The motivation is to make sure that no traffic is allowed when there is
no VPN connection.

oh, I see, okay, now understand the intention.

did you try Wireshark on Qubes before ?
or maybe there is, more suitable alternative for Qubes ?

with your design, sys-net - firewall - vpn - firewall,
in case we want to monitor LAN traffic, by using Wireshark,
in which VM we should install the Wireshark ?

by the way, I read this in wiki

ME has full access to memory (without the owner-controlled CPU cores having any knowledge), and has full access to the TCP/IP stack and can send and receive network packets independently of the operating system, thus bypassing its firewall.

Wireshark on Qubes?

I haven’t used it in Qubes yet.

in which VM?

I would do that in sys-net to be sure I see everything.


My ME is neutered and the disable bit is set. Booting with
Coreboot/HEADS. It’s not perfect but better than the default.

Random VPN questions!

(1) If I have
AppVM → sys-vpn → sys-firewall → sys-net,
is sys-vpn supposed to automatically get DNS from AppVM?

I have to manually edit /etc/resolv.conf in the AppVM for DNS to work…

(2) What is the purpose of using VPNs, when tor is available?

I’m assuming tor offers better privacy.(more nodes, no financial link). All low-bandwidth activities should therefore default to tor. This leaves the following for VPNs, (a) high-bandwidth activities that don’t block VPNs, and (b) low-bandwidth activities that block tor, but don’t block VPNs.

Unfortunately, streaming video sites like Netflix etc, block VPNs. The only thing I can think of is google searching (falls under (b)).

Ideally, appvm should not need to edit /etc/resolv.conf. However, if the DNS server is static, I don’t think it’s wrong thing to do. But if you want to change network proxy for your appvm, the DNS server might not work anymore, so it is best to handle in sys-vpn and just leave appvm /etc/resolv.conf as it is set up by Qubes.

sys-vpn needs to redirect DNS requests from clients to desired DNS server (usually the one offered by VPN provider) using ipfilter nat rules. This is done automatically if you are using NetworkManager in sys-vpn with qubes-setup-dnat-to-ns hook in /etc/NetworkManager/dispatcher.d/qubes-nmhook.

If you are not using NetworkManager (as adviced by some tutorials), you need to do it by yourself. It is a bit tricky if the DNS server is not static. In practice, you need to parse the /etc/resolv.conf in the sys-vpn and then add the redirection rules, or perhaps run qubes-setup-dnat-to-ns (not sure if it works just like that).

This tutorial is for setting up manually Mullvad VPN, but the section “Add DNS hijacking script” can be adapted to other setups as well if the DNS servers are static: Mullvad on Qubes OS 4 - Guides | Mullvad VPN

Thank you – I was wondering why it doesn’t work automatically with my VPN’s GUI app.

I did it simply by running the GUI app (for quick connection switching) and enabling “netork-manager” service in the vm settings / Services. NetworkManager hooks take care of DNS server changes automatically, and the clients won’t need to worry about that.

My ME is neutered and the disable bit is set. Booting with
Coreboot/HEADS. It’s not perfect but better than the default.

hi @Sven do you mind to suggest me tutorial / reference ,
that you use to neuter and disable ME , install Coreboot/HEADS ?

sys-vpn needs to redirect DNS requests from clients to desired DNS server

if we don’t use sys-vpn ( appVm - sys-firewall - sys-net ) ,
does it mean, there are 3 DNS server configuration now , in each VM ?
if there are really 3 DNS server, then which one will be used as reference ?

If I understand it correctly, It will be a chain of redirections, eventually whatever is in sys-net /etc/resolv.conf will be used. Typically it will get something from ISP.


  1. In appvm, there’s and in /etc/resolv.conf
  2. These are translated in sys-firewall to whatever is in /etc/resolv.conf (usually the same), and passed on to sys-net
  3. In sys-net, and are again translated to whatever is in /etc/resolv.conf, this time usually something offered by the ISP

End result is: appvm doesn’t need to change anything, just leave the /etc/resolv.conf as it is. If you want to change the DNS server, it is best to do in one of the network-providing qubes.

Not quite right.

DNS is handled like this, by default:

  1. Each appVM has and
  2. At a netvm traffic to these addresses is passed unchanged upstream by a firewall nat rule.
  3. In sys-net, traffic to these addresses is routed to whatever sys-net uses for DNS.

It’s all done by firewall nat rules.
If you change the DNS settings in a qube, this traffic will simply be
passed upstream without change.

If you insert a sys-vpn, then that netvm should block all upstream
traffic except to the VPN, and should rewrite the DNS calls to whatever
is provided by the VPN provider.

Thanks for clarifying. This part was a bit unclear to me. I mean, that’s the observation, but was just wondering what would happen if network-providing qube has non-standard /etc/resolv.conf?

Nothing - it will only affect traffic from that qube.

You need a computer that is supported by HEADS and Qubes OS. Currently
I think that list is pretty short:

ThinkPad X230
ThinkPad T430

If you have one of those, ask @Plexus if you may see his draft tutorial.

1 Like