Networking between qubes and HVMs

202 views
Skip to first unread message

jmarkd...@gmail.com

unread,
Oct 3, 2018, 11:10:10 AM10/3/18
to qubes-users
I want to allow a debian qube to use a BSD qube as its network and to allow traffic between them. The BSD sees the vif created for the debian when I do this, but no traffic passes between them. In the firewall settings for debian qube I get a warning that its not attached to a firewall vm so no traffic is allowed.
Is there a way to override this? I saw in qubes docs there is a way to do this for template based qube vms, but what about for an HVM and a qube?

unman

unread,
Oct 3, 2018, 11:42:59 AM10/3/18
to qubes-users
On Wed, Oct 03, 2018 at 08:10:10AM -0700, jmarkd...@gmail.com wrote:
> I want to allow a debian qube to use a BSD qube as its network and to allow traffic between them. The BSD sees the vif created for the debian when I do this, but no traffic passes between them. In the firewall settings for debian qube I get a warning that its not attached to a firewall vm so no traffic is allowed.
> Is there a way to override this? I saw in qubes docs there is a way to do this for template based qube vms, but what about for an HVM and a qube?
>

There was a recent post on exactly this issue.
I do this with an openBSD HVM as netvm.
My solution is to attach both HVM and qubes to a (non-networked) fw.

https://groups.google.com/forum/#!topic/qubes-users/iQm9-rrCDIY

unman

jmarkd...@gmail.com

unread,
Oct 3, 2018, 1:47:20 PM10/3/18
to qubes-users
I literally just read that and going to post an apology for repeating a question

unman

unread,
Oct 4, 2018, 10:20:35 AM10/4/18
to qubes-users
On Wed, Oct 03, 2018 at 10:47:20AM -0700, jmarkd...@gmail.com wrote:
> I literally just read that and going to post an apology for repeating a question
>

No problem.
If you need some further pointers shout out.

jmarkd...@gmail.com

unread,
Oct 9, 2018, 8:43:56 AM10/9/18
to qubes-users
I am still having difficulty getting these vms to be reachable with each other. Basically what I want to do is have a home security/automation vm, and a freenas vm, communicate with the outside world and with the vm that controls my access points/physical switches.

Currently I have the usual sys-net/sys-firewall. Each service vm(access points, freenas, etc.) Has its own firewall vm. Those fireall service vms are all connected to sys-firewall.

I followed the instructions in the qubes-firewall docs setting up forwarding between the service firewalls to travel through sys-firewall. And each service firewall vm(and their associated service vm), can ping every firewall vm in the system. But the actual service vms themselves cannot ping each other.

So for example: freenas vm > freenas vm firewall > sys firewall > home security firewall vm.
All will allow ping, but i cant get freenas to talk to home security vm, as i intend on using the nas storage to store the camera footage.

Similarly the home security vm can do the same amount of pings, but fails to talk to freenas.

I suspect NAT is the issue but lack the knowledge base to enable this to work.

I am not particularly dead set on using all these firewall vms either but this is the config thats gotten me the furthest so far.

unman

unread,
Oct 10, 2018, 9:01:02 AM10/10/18
to qubes-users
I'm not sure what pourpose you had in mind when putting in those extra
firewalls. Undoubtedly they will complicate matters further. Are you
intent on keeping them?

What template are you using for sys-firewall? The instructions should
be updated to cover nft which is now the default in Fedora templates,
rather than iptables.
Which template are you using for sys-net?




jmarkd...@gmail.com

unread,
Oct 11, 2018, 4:57:32 PM10/11/18
to qubes-users
Its a fresh install of 4.0 and im using default sys vms.

Id rather not have all these vms as the overhead is pointless.

I also did not realize there was a switch, ill read up on nft.

jmarkd...@gmail.com

unread,
Oct 11, 2018, 9:02:56 PM10/11/18
to qubes-users
I guess to further clarify what I want to try to do is have sys net be connected to the interface that is connected to my modem(to the ISP/world).

I would like another vm to control all(or some) other
physical interfaces on my machine (access points/etc..).

I would like a qubeVM from within the machine running qubes to be able to connect via those physical interfaces as if they were also attached to the physical interface.

Ideally so that the qubes OS is segregating physical NICs along with applications.

So lets say FreeNAS is running inside qubes. And someone near my access point wants to use freeNAS via wifi, they would log in via ssh or whatever over the access point.

But if that same someone is somewhere else they can ssh or whatever to freeNAS via the internet and the wan NIC that sys-net controls.

unman

unread,
Oct 15, 2018, 8:59:52 AM10/15/18
to qubes-users
That makes it much clearer to me. Thanks.

There are a number of different ways to approach this, but the one that
seems easiest would be something like this:

sys-net -- sys-fw -- freeNAS
| -- qube1
| -- wifi -- qube2

wifi is set up to "provide network" - ie it's a NetVM, and acts as
access point via attached wifi.

Setting up access via sys-net to freeNAS is straightforward, and already
documented, as you know. I suggest you get that working first.

Provisioning the wifi qube should be straightforward.
You will need to set up the wifi access point, and then configure port
forwarding to freeNAS. sys-fw should be the default route set on wifi
qube. Depending on whether you want downstream clients (like qube2) you
may want to change this.
You will need to set fw rules to allow traffic between these vif
interfaces.
You will need to adjust routes to ensure that traffic arriving at
freeNAS via wifi does not get sent out via sys-net. The simplest way to
achieve this will be to use source NAT on wifi, or Masquerade, depending
on your configuration.

Note that qube2 can connect EITHER to freeNAS port OR to external IP of
sys-net. If you don't want this, either have no qubes connected
downstream of wifi, or adjust fw on wifi to block traffic from all vif
interfaces to eth0.

If you need help with the details, just ask.

unman
Reply all
Reply to author
Forward
0 new messages