I’m still getting used to Qubes and how I plan on using it beyond as a personal browsing OS. In this case, I’m trying to provide local net services via an App Qube–no, I’m not perfect, I’m sure if I were better at this, I’d have a disposable app Qube working as a service client along with an app qube that’s actually keeping logs. So this is me just setting up a basic bridge to a hosted service in a service VM, Emby Media Server. I thought I could run a Debian XFCE minimal host with the DEB installed for Emby, and pass a USB device for ethernet directly to this qube. So, now with the intro, here’s where I’m at:
How am I going to tell where the packets coming to this USB Ethernet Dongle’s IP drop off? The App Qube ‘provides networking’, so I’m assuming this is why the USB Dongle will officially connect to the local DHCP server. However, from what I’ve read, the only VM that’s actually listening on IPs on behalf of my whole machine is the sys-net VM. In other words, I need to attach the USB dongle to the sys-net VM instead–how do I pass things through on this device directly to the Qube, then, even if it passes through sys-firewall? Isn’t attaching an ethernet device directly to the Qube enough?
I’ve passed by topics on security regarding this–like an insecure dongle, an insecure network, so I would appreciate advice that makes these nuances even easier, since I would like HTTPS, would need to get Certbot via a No-IP exposure… see how expansive this gets? Let’s just help me get my debian server responding via packets on this dongle, I hope.
Let’s go, Qubes! Peace.
~Philene/Philien
PS: My only and best workstation is Qubes and so I am pulling out hairs trying to do anything substantial beyond web-browsing. Shoutout to people who I have open pull requests with, I can’t even work in a branch checkout right now.
Let’s say my first thought is to create a clone of sys-net and attach the emby USB dongle to this sys-VM. Then what? Then the emby Debian VM has its default network as the emby-sys-net vm? Wouldn’t this mean all networking requires the dongle, instead of just the local Emby service?
(Hm, yes, the internet of the emby Qube is based on sys-firewall.)
It is possible to provide network via netvm as well as a network interface device, this is up to you
If you create a sys-net clone to operate your usb dongle it will have its own access to the internet, separate from the default sys-net (assuming that the dongle and whatever other network devices you have in the default sys-net aren’t on the same network outside of QubesOS), so no, all networking doesn’t require the dongle
p.s. If your concern comes from sys-firewall, then yes, you need to have separate sys-firewall as well (or to not use it at all).
In another word, if your goal is to separate networks using QubesOS model, then you need something like:
What a sublime and comprehensive reply, @otter2 I learned a lot in just reading 2/3rds of these documents. The last one was some icing on the cake when it comes to Qubes history and other types of networks.
When I was following the Firewall instructions on the example of letting a single port forward passthrough, I was getting an error about the sudo nft add rule basically saying there’s no rule chain on sys-firewall matching the one in sys-net. (Error: Could not process rule: No such file or directory.) I thought the easiest answer would be to reboot sys-firewall and didn’t get the rule being created. Does the tutorial miss some flush step or something? Maybe it needs one third reminder of where each step’s rules take place.
As I went along, I think I ended up learning a lot more about networking between Qubes, as the ‘four steps’ step really helped out. My network frames weren’t showing up on sys-net via the hub. Your network diagram of Qubes running sys-net and sys-net-usb (I’d say) for Emby didn’t necessarily show my ending case. From what I understand in your case, my Emby Server is still a normal Qube, connected to the Qube net, just not via sys-firewall for outgoing connections. However, the incoming and internetworked connections would not exist and would all need to be routed by the user using nft rules. In other words, my USB packets aren’t picked up within sys-net or sys-firewall because neither has USB devices by default. If I add it to a sys-net-usb I create a separate bandwidth of network current, so network interface in your diagram does a LOT of work for the diversity of network interfaces for Qubes, sys-net-usb being my case of the most basic example.
I’d need to create a separate route of network packages based on firewall routing rules between the servers–some accepting incoming connections on that parallel-running listening/port on the system. That’s all the instructions the four-sections of networking examples gives, passing them from one network (external) to the internals of another. (/Networking 101)
So in that case, the Emby server could have all outgoing network connections, excluding those incoming from the sys-net-usb, routed to it from this network, but that it would just choose its default gateway network as (sys-firewall/etc).
I’m assuming this might be really helpful, please make replies directly to this post for notes or additions. Thank you, @otter2. If you have other thoughts put them back into the main thread, since this networking lesson needs playbook recipes.
It works for me, what have you tried? Reboot is not required.
For all connections, not just outgoing
User needs to set up port forwarding in qubes network regardless of whether qube is using the default sys-firewall or another firewall. The most direct way to avoid this is to attach the network interface to your server qube and set netvm to nothing.
Perhaps you are interpreting sys-net and sys-firewall in the doc literally? You can do the same with your custom network qubes.
Also can you maybe make a diagram of what you’re trying to do? I might’ve misunderstood your intentions.
I learned a lot in just reading 2/3rds of these documents. The last one was some icing on the cake when it comes to Qubes history and other types of networks. 
