This is all more or less based on an excellent blog post by Micah Lee.
I’ll try to explain again with more detail:
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.
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.
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.
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.
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.
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.
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 https://github.com/tasket/Qubes-vpn-support
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 ?
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.
(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 | Mullvad VPN
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.
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.
So:
In appvm, there’s 192.139.1.1 and 192.139.1.2 in /etc/resolv.conf
These are translated in sys-firewall to whatever is in /etc/resolv.conf (usually the same), and passed on to sys-net
In sys-net, 192.139.1.1 and 192.139.1.2 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.
At a netvm traffic to these addresses is passed unchanged upstream by a firewall nat rule.
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?