Can someone explain networking

OK so, templates no network and appVM’s have network and that’s where in messed up I gave templates network…

sys-net is clearnet access???
sys-whomix is tor, I understand this

sys-firewall, what is it’s role in network access if both sys-net and sys-whonix go down two different paths to get internet. and they both use sys-firewall

1 Like

sys-net is people outside home,
sys-firewall is a front door of your home,
sys-whonix is one of door inside your home,

you can build many door / room (we can call it a qube) .

take a look at this Partitioning my digital life into security domains | The Invisible Things

she build a good world, and that’s inspire me.

2 Likes

I’ve watched a presentation by Micah Lee on youtube, titled “Qubes OS: The Operating System That Can Protect You Even If You Get Hacked”. I think he mentioned that he made a route to a qube where the qube went to tor then to the internet by VPN (VPN over TOR?), so he didn’t get a torified address, but an address by his VPN provider. How can someone make something like this?

Okay, back to your questions:

OK so, templates no network and appVM’s have network and that’s where in
messed up I gave templates network…

Yes (for the first part) and for the second - have you tried to check, if the templates get updates (by doing this via right click of the template and “Update qube” or even by right click on the orange star in the taskbar and running the salted update function) when those templates don’t have sys-net as netVM ? It should work via proxy, unman mentioned…
And thats it! You don’t need more for running those templates.

sys-net is clearnet access???

yes

sys-whomix is tor, I understand this

yes

sys-firewall, what is it’s role in network access if both sys-net and
sys-whonix go down two different paths to get internet. and they both use sys-firewall

you more should understand it that way:
sys-net is clearnet/for all VMs which connects “clear” and sys-whonix is for the path to tor/for all VMs which needs to connect “tor”
AND sys-firewall is the shield for ALL VMs (the clearnet’s and the tor’s),

so the way out should be for all tor connections:
Your Tor cube (whonix-ws/anon-whonix) → sys-whonix → sys-firewall → sys-net → internet

and for all clearnet connections:
Your clearnet cube (work/personal/untrust) → sys-firewall → sys-net → internet

But you even can run a WORK cube → sys-whonix → sys-firewall → sys-net → internet
It depends on you and what you want to do.

1 Like

thank you “The gardener”, yes I understand what you are saying… I understand this but in a template or appvm qube setting I can only chose 1 option (sys-net, sys-firewall, sys-whonix). That’s were I get confused. So if I need tor I would chose sys-whonix. if I want clearnet I would chose sys-net. So then or why would I chose sys-firewall? Or would I chose sys-firewall if the template or appvm needed no network/internet.

This the last thing I am trying to understand with qubes. And the “yellow triangle” next to networking drop down in qubes settings where I chose (sys-bet, sys-whonix, sys-firewall) that I have with some of these appvms where I changed networking. And what is the importance of these “yellow triangles” with that message.

1 Like

Make sure you keep “none” for templates.

Yes.

Unless you know what you are doing, don’t choose sys-net. Just use sys-firewall for clearnet. sys-firewall provides additional filtering capabilities if you want to limit services and IP addresses a qube can connect to. Though if you don’t use them, then maybe this doesn’t make any difference.

See this thread: Qube Settings Caution Bang: What's this mean?

1 Like

as @ 427F11FD0FAA4B080123 said.

Template Vm never ever any kind of network access. Choose “none” in the qubes manager.

AppVM only to sys-firewall or sys-whonix but be careful here. If you set up an AppVM with a cloud account like Nextcloud,Seafile whatever or Email account or you’re normal browser with bookmarks and no hardening like disabling webrtc… you’re whole tor routing setup is useless. even worse it lets you stand out like a oiltank in the ocean. ^^ (unless your accounts where setup over tor than the other way around never ever connect to these accounts over clearnet )

So to make clear.

Sys-net is like your router

sys-firewall is like a firewall behind your router

firewall settings in the AppVM Qubes Manager is like your normal desktop firewall.

If sys-net gets compromised, you have your firewall as a second layer of protection and sys-firewall helps you to make firewall rules setup easier. Block everything outgoing you don’t need.

sys-whonix gateway. is like a router behind your firewall behind your router , that routes every connection throught tor.

choose wisely

1 Like

thank all of you for such a detailed explanation on qubes networking… it really helps me out.

@dispuser5132…i fully understand what you are saying. I only access email via a disposable appVM. I don’t do ANY cloud services, “I fully control my data and don’t need anyone managing it”. But I do have bookmarks in my “anon-whonix” tor browserappVM… so this is a bad thing?

I’m not an expert but that tor vpn thing sounds not really useful. At the end its all in the same network which means he connects to the vpn provider from his ISP IP. I dont know what he tries to acomplish with that but from what i understand he tries to be clever and want to hide his IP from VPN Provider. As tor and vpn connection come from the same computer in the same network it will not work. Because everything is routet through sys-net. Sounds like a cool h4ck3r tutorial…

no I don’t have any VPN yet. I have read and heard they are not all what they are cracked up to be. But I am doing my own "vsp"build in qubes . Have to chose a template and build out , to a openvpn but that’s a few weeks away yet I think that is a better plan.
But going to install faster new ssd’s reimahe and build out from their for qubes now that I am fully understanding this OS better

bookmarks in “anon-whonix” is not really a problem. But remember every change you do to the tor browser could let you stand out. Browserfingerprinting…

Email through disp Vm… hm you can do that. I would prefer a standalone VM only for emailing with firewall rules setup for ports and domain and again, never switch them between tor and clearnet. That would rise a red flag on providers site. But of course it depends on the provider…

will not really email with disposable vm. LOL none of the settings stay and configs as well as email address. I have to keep re-entering everything… LOL
But hell it was worth a shot

What openvpn vsp in qubes os ?

So you want to build an appvm as your own vpn server ?

I hope i did not understand that right

well I am still researching it and it appears ot can be done…
You have to pick a OS “template” like Ubuntu and install config files and set it up somehow to link to the services. Like I said I am still researching it be looks very good to do. everything hosted on you own system and linked together

as for “fingerprinting”,i know so I need to come up with a way around this. Maybe ise disposal anon-whonix" appvm, something like that. Don’t know yet

ok i dont know if i misunderstood your project… but if i understand you right. that is a really bad idea. You want to host your own vpn server inside your qubes os and then connect to that “vpn” with your AppVMs?

1 Like

Not quite sure what you are trying to achieve, but you are going about
it wrong.
What you can do is set up a qube with your settings, then mark that
qube as a template_for_dispvms. Then a disposableVM can start with the
settings already there.
I use this to run a “split mail” set up, where the receiver and sender
are running in disposableVMs, and the mail client is running in a
minimal, offline qube.

sounds nice. to understand you right, you setup an AppVM with mail client configured to access the email server (hoster), then use that AppVM as a template for disposableVMs? Sounds nice. But i dont get the split part. Or do you have one template for imap and one template for smtp and based on that disposable VMs ?

thanks :slight_smile:

There are two ways of working with Tor and VPN. Qubes makes it somewhat
easier to try out both.

Tor over VPN:
qube->tor->Vpn_qube->sys-firewall->sys-net

This hides the fact that you are using Tor from anyone watching your
external IP - all they will see is traffic going to your VPN provider.
(They may be able to guess you are using Tor by traffic analysis though.)
Your VPN provider will see the Tor traffic.
You trust the VPN provider to do the right thing.
If anyone were to break Tor then the trail would lead back to the VPN.

VPN over Tor:
qube->Vpn_qube->tor->sys-firewall->sys-net

This hides the fact that you are using the VPN from anyone watching your
external IP - all they will see is Tor traffic.
Your VPN provider will see traffic coming from a Tor exit node.
If anyone were to break Tor then they would see encrypted traffic at the
exit node heading to and from the VPN provider.
You trust the VPN provider to do the right thing: in this case the VPN
sees everything you do.

There is a huge warning about trying to do this - it’s in the Tor
FAQ.

You can read more at

1 Like

Briefly, I have 3 qubes:

  1. fetcher - configured with getmail. template_for_dispvms
  2. mutt qube - no netvm - where I read and write mails. Based on a minimal
    Debian template. Any attachments are opened in offline disposableVMs.
  3. sender - configured with msmtp. template_for_dispvms

So fetching and sending are done from network connected disposable
qubes. The work is done in a minimal qube that is offline.

There’s a more detailed note at GitHub - unman/notes under
SplitMutt.md
It sounds like work, but the initial fetching, transmission in to mutt inbox,
and the syncing outgoing to sender, and sending are just two keyboard
shortcuts. After the initial set-up the process is transparent, just the
way it should be.

2 Likes