How to share internet from one VM to another \ how does whonix gateway creates network?

User Support
1

You can attach one VM to gw-15 and get torified connection. But if you’d try to get connection from fedora-30\32, ubuntu-20.04, debian-10, ws-15 (which is reasonable) - it won’t work. Host will be unresolved and unreachable, no matter if ProxyVM attached to sys-firewall, sys-net of some gw-15. R4.0.
This limits isolation, since you can set up a VPN\proxy\mixnet only in a same vm where tor-client is running, and
a) if tor-client would be magically compromised - attacker could route connections not only around tor-mixnet, but also around your vpn\proxy\mixnet too.
b) if your VPN software with next upgrade will receive malware patch, say due to some supply chain attack - it could also replace tor with something else.
Because they’re in a same VM.
But I’m interested in it simply cause I can’t install mixnet-client in a gw-15 yeah…

How do I create network for other qubes from (i.g.) ubuntu 20.04?

In links above heavily implied that it does not require any additional manipulations. Well I tried a lot of combinations (without any VPN\proxy in ProxyVM, just to share the network) and only gw-15 as ProxyVM worked. No other OS (with exception of sys-net and sys-firewall). In a githib link ProxyVM is based on debian-10 though (it 6 months old, which is not a long time for qubes).

Speaking of “how whonix gateway creates network?”, there’s one unique thing about gw-15, If you check ifconfig in it, it’s got:

Persistent two eth’s instead of single one

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet *ip1*  netmask 255.255.255.255  broadcast 10.255.255.255
        ether *mac1*  txqueuelen 1000  (Ethernet)
        RX packets 107722  bytes 59830813 (57.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96652  bytes 23618902 (22.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet *ip1*  netmask 255.255.255.255  broadcast 10.255.255.255
        ether *mac2*  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

For each connected qube it’s got virtual interface

vif24.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet *ip1*  netmask 255.255.255.255  broadcast 0.0.0.0
        ether *mac3*  txqueuelen 32  (Ethernet)
        RX packets 6265  bytes 311865 (304.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7544  bytes 4615257 (4.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Couldn’t find a clue in docs how this supposed to work.

My iptables in gw-15. Don’t understand what rules are responsible for creating network and stuff… Also doubt it’s even in iptables since it just a firewall.

I don’t know where else to search this and which keywords to use. Why so hard…

2

I’m not sure exactly what to address first since I’m relatively new to Qubes but perhaps this will help clear some things up.

  1. I assume when you write (whonix-)gw-15 and (whonix-)ws-15 that you are referring to the respective Whonix Gateway and Workstation TemplateVMs.

  2. The sys-whonix NetVM is based on the whonix-gw-15 TemplateVM; when you say

You can attach one VM to gw-15 and get torified connection

I assume you are in reality attaching a VM to sys-whonix. The whonix-gw-15 TemplateVM doesn’t have networking by default, so unless you’ve added networking to it perhaps via the Qube Settings GUI, you shouldn’t be able to use it to connect to the internet, much less to Tor.

Non-Qubes Whonix implements two VMs, just like Qubes-Whonix. The Workstation VM handles all normal OS functionality such as web browsing, email, and document processing. All the networking for the Workstation VM, however, is passed to the Gateway VM, which sends all traffic to Tor. This dual-VM setup has many advantages.

Qubes-Whonix implements the Whonix VMs in the same manner, but using “Qubes” logic. Thus the Workstation VM you use everyday (i.e. anon-whonix) is really an AppVM based on the whonix-ws-15 TemplateVM, and the Gateway VM you use everyday, sys-whonix, is really a NetVM based on the whonix-gw-15 TemplateVM.

Since sys-whonix is a NetVM, any VM you “attach” to sys-whonix will have all its network traffic routed through Tor. “Attaching” a NetVM to another VM means, for all intents and purposes, opening up the Settings GUI of a VM to the Basic tab, clicking the Networking drop down, and selecting the NetVM which you would like to provide internet connectivity to your VM.

  1. Only NetVMs can provide internet access to other VMs. The other two (default) NetVMs are sys-net and sys-firewall. From what I understand, sys-net is the last VM to handle your traffic before it heads to the internet. sys-firewall is the penultimate VM to handle your traffic, and, as its name suggests, provide functionality akin to a firewall, blocking certain traffic from ever entering sys-net. Any VM whose traffic should go to the clearnet (i.e. not Tor, not I2P) should typically be connected to sys-firewall. Any VM whose traffic should go to Tor should (at some point) be connected to sys-whonix and then at the end of the chain to sys-net.

When you say you

try to get connection from fedora-30\32, ubuntu-20.04, debian-10, ws-15 (which is reasonable) - it won’t work

it is not working because those VMs aren’t NetVMs.

  1. The mixnet-client seems to be related to Nym or the Nym network. I’ve heard of this before but don’t know any details. It looks like mixnet-client is an application that needs to connect to the internet. If so, it could either run in an AppVM based on a TemplateVM; it would then need to be connected at least to sys-net, if not to sys-firewall. If mixnet-client needs to serve internet traffic to other VMs, then you could create a new qube, either standalone or based on a template, and in the Advanced tab in the qube creation window select “provides network to other qubes.” If mixnet-client needs to send traffic that sys-firewall blocks, then you could connect your mixnet-vm straight to sys-net. I don’t know if this is all you’d need to do to have your “mixnet-vm” act as a NetVM and serve “mixnet” traffic to VMs that used it as their networking, but I would think those are the most important steps.

Please let me know if you have any questions about something I didn’t explain well enough or at all.

3

Hello @qubes-kernel-5.8 and thanks for your detailed answer.

First and second assumptions about Whonix were true, but I didn’t specified in an original post - that I have multiple ProxyVMs, based on whonix-gateways-15 template. But there nothing special about them, so it’s safe to think about sys-whonix as it’s just a gw-15-based VM too.
Also, every VM I tried to use as a ProxyVM was connected either to sys-firewall or sys-whonix, and was checked as “Provides network”. And every template I have - has sys-whonix attached (for updates).

Well I think this is wrong.

  1. As stated before, I had network connected (in a form of using sys-whonix or sys-net as a NetVM for ProxyVM) in every VM I tried to use as ProxyVM.
  2. I don’t think that definition in docs you’re referring to is outdated (as it said right below the headline). But it doesn’t matter because I don’t want to use, say, ubuntu-20.04 as NetVM. I want to use it as ProxyVM. ProxyVMs can provide network too, i.g. sys-whonix is a ProxyVM.

First of all I want to say, that I did my tests without running mixnet-client. And yes, ProxyVM with it was connected (to sys-firewall or to sys-whonix) and there was confirmed internet on it. But ProxyVM couldn’t share it’s internet (with or without running mixnet-client) and that’s my problem.

Which I did and which didn’t worked (no internet on connected to ProxyVM qubes).

4

Taking these

How do I create network for other qubes from (i.g.) ubuntu 20.04?
ProxyVM couldn’t share it’s internet (with or without running mixnet-client ) and that’s my problem

as your main issues, I myself would double check the steps to create a VPN ProxyVM and check the VPN ProxyVM Troubleshooting page. You can also check out this guide to setting up a VPN ProxyVM.

If the ProxyVM is set up correctly, it seems based on the VPN ProxyVM documentation that the only general step when creating a ProxyVM is to check “provides networking to other qubes,” and all the other steps are specific to the proxy service you are running. Thus when you say that your ProxyVM didn’t share internet to other VMs, perhaps that is because there is no proxy service (i.e. OpenVPN) running in the ProxyVM.

If I create a ProxyVM, it shares internet with qubes connected to it. I did these steps:

  1. Click “Create New Qube” and make an AppVM named proxy-vm based on fedora-33 template and select sys-firewall as the networking for proxy-vm
  2. Click the “Advanced” tab and check “provides network to other qubes”. Leave everything else as is.
  3. Turn on proxy-vm
  4. Make proxy-vm the NetVM of one of your qubes i.e. work
  5. Turn on work and enjoy the internet

I’m still a bit unsure if you’d like to use Tor in your network connectivity, and what role you’d like something like sys-whonix to play. If it helps, I ran the iptables commands you ran in your sys-whonix in my sys-whonix and I got the same output.

5

Thank you for the test! I think that proves, that the issue is not in a (not) running proxy service. Also, did the same steps (after installing fedora-33 template which i didn’t originally had) - and it didn’t work. AppVM was based on ws-15, then I tried to connect with another fedora-33 VM (so f-33 to f-33) - and it worked. Then I ran some more tests and came to conclusions:

  1. Most OS can share to and receive internet from other qubes.
  2. Whonix Workstation 15 can’t. It can receive internet only from Whonix Gateway.
  3. Whonix Gateway needs to restart tor after switching network qube.

So, I guess this trouble is kind of solved (except I count ws-15 requirement for gw-15 as a flaw, but devs sure got strong reasons on that).

P.S. Weird how forum dedicated to privacy-centered OS requires JS for basic functioning (like log in or write a reply). But yes, all nojs-alternatives have worse UI.

1 Like
6

Glad to hear you got something working.

Yes I wonder if Qubes could self-host a forum. I’d be more comfortable with that.

7

A post was split to a new topic: Can I avoid javascript on the forum?