Full networking between VMs

[arthur....@gmail.com]

My use-case for Qubes is largely to help segment my work/personal systems as well as allow me to run VMs for development. That second part is a bit of a challenge, though. By design, whenever I spin up a new VM, I have to explicitly allow ports between the VM and my existing systems. I 100% understand why this is the case from a security perspective. However, for my use-case, I'd like the sys-firewall to behave more like a traditional hypervisor like ESXi.

With full acknowledgement that my question goes against the default security principles of Qubes, what firewall rules would I need to configure to allow full networking between my VMs? By no means am I an iptables guru, so I need a little help . . .

Thanks!

[Sven Semmler]

On Mon, Mar 16, 2020 at 08:21:24PM -0700, arthur....@gmail.com wrote:
> With full acknowledgement that my question goes against the default
> security principles of Qubes, what firewall rules would I need to configure
> to allow full networking between my VMs?

This looks like what you want:
https://github.com/Rudd-O/qubes-network-server
(last updated in Nov 2018)

/Sven

--
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

[arthur....@gmail.com]

Interesting. It seems a little dated, though. Have you ever used it?

On Monday, March 16, 2020 at 11:10:22 PM UTC-5, Sven Semmler wrote:

[Sven Semmler]

On Mon, Mar 16, 2020 at 09:16:40PM -0700, arthur....@gmail.com wrote:
> Interesting. It seems a little dated, though. Have you ever used it?
>
> On Monday, March 16, 2020 at 11:10:22 PM UTC-5, Sven Semmler wrote:
> > This looks like what you want:
> > https://github.com/Rudd-O/qubes-network-server
> > (last updated in Nov 2018)

Nope. I don't have your use case. I wonder if plain vanilla hypervisors
wouldn't be a better fit for you.

[arthur....@gmail.com]

Qubes is the only well-maintained type-1 client hypervisor that exists as far as I know. I tried XenClient earlier in the decade, and it was an awesome product in my opinion. However, it ceased development.

I think my use-case could be accomplished via iptables rules, but as I mentioned, I've never been very good with those rules and don't use it enough to have become proficient. This page is a good starting point and specifically mentions my use-case:

https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes

However, rules have to be added to sys-firewall and each VM on a per-IP basis. I would think there is a way to add a rule to sys-firewall that would open networking between all VMs by using CIDR blocks. Yes? No?

For those still concerned with security, it would always be possible to have two sys-firewall VMs: one to provide the default isolation and one to allow networking between systems. That would be a great setup, but I just don't know how to do it.

On Monday, March 16, 2020 at 11:31:17 PM UTC-5, Sven Semmler wrote:

[unman]

On Tue, Mar 17, 2020 at 08:03:51AM -0700, arthur....@gmail.com wrote:
> Qubes is the only well-maintained type-1 client hypervisor that exists as
> far as I know. I tried XenClient earlier in the decade, and it was an
> awesome product in my opinion. However, it ceased development.
>
> I think my use-case could be accomplished via iptables rules, but as I
> mentioned, I've never been very good with those rules and don't use it
> enough to have become proficient. This page is a good starting point and
> specifically mentions my use-case:
> https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
>

> However, rules have to be added to sys-firewall *and* each VM on a per-IP

> basis. I would think there is a way to add a rule to sys-firewall that
> would open networking between all VMs by using CIDR blocks. Yes? No?
>
> For those still concerned with security, it would always be possible to
> have two sys-firewall VMs: one to provide the default isolation and one to
> allow networking between systems. That would be a great setup, but I just
> don't know how to do it.
>
> On Monday, March 16, 2020 at 11:31:17 PM UTC-5, Sven Semmler wrote:
> >
> > On Mon, Mar 16, 2020 at 09:16:40PM -0700, arthur...@gmail.com
> > <javascript:> wrote:
> > > Interesting. It seems a little dated, though. Have you ever used it?
> > >
> > > On Monday, March 16, 2020 at 11:10:22 PM UTC-5, Sven Semmler wrote:
> > > > This looks like what you want:
> > > > https://github.com/Rudd-O/qubes-network-server
> > > > (last updated in Nov 2018)
> >
> > Nope. I don't have your use case. I wonder if plain vanilla hypervisors
> > wouldn't be a better fit for you.
> >
> > /Sven
> >

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

In *full* knowledge of what you are doing you probably only need to add 1
rule at the sys-firewall level in the FORWARD chain:
iifname "vif*" oifname "vif*" accept
You will still need to add incoming allow rules in INPUT chain per qube, depending on
what service they offer. Not a huge issue.

The idea of having multiple sys firewalls is easy to implement, depending
on how you want it to work. Give some more detail on exactly what you
want. (Clearly stating the aim is the first step toward solution.)

[arthur....@gmail.com]

On Tuesday, March 17, 2020 at 10:57:39 AM UTC-5, unman wrote:

Sorry for the top-post. I always forget that about Google Groups.

The command you listed:

iifname "vif*" oifname "vif*" accept 

Is that a proper iptables rule, or are there placeholders in there that I need to change specific to my system? Since iptables syntax is rather unclear to me, I want to be sure before I go running things in my sys-firewall. Shouldn't it be something like this?

sudo iptables -A FORWARD -i "vif*" -o "vif*" -j ACCEPT

Then, in each one of my client qubes, I would run something like this:

sudo iptables -I INPUT -i "vif*" -j ACCEPT

If you could help me get the syntax right, that would be super helpful! Thanks!

[unman]

On Tue, Mar 17, 2020 at 12:13:57PM -0700, arthur....@gmail.com wrote:
>
>
> The command you listed:
> iifname "vif*" oifname "vif*" accept
>
> Is that a proper iptables rule, or are there placeholders in there that I
> need to change specific to my system? Since iptables syntax is rather
> unclear to me, I want to be sure before I go running things in my
> sys-firewall. Shouldn't it be something like this?
> sudo iptables -A FORWARD -i "vif*" -o "vif*" -j ACCEPT
>
> Then, in each one of my client qubes, I would run something like this:
> sudo iptables -I INPUT -i "vif*" -j ACCEPT
>

Sorry Arthur, that's nftables syntax.
For iptables, you would want:
`sudo iptables -I FORWARD -i "vif*" -o "vif*" -j ACCEPT`
because you want that rule to PRECEDE the existing one that blocks
traffic.

For nftables I would rewrite the FORWARD chain and atomically rewrite it at
sys-firewall startup.
You can do this by using the scripts in /rw/config.

[arthur....@gmail.com]

On Tuesday, March 17, 2020 at 9:25:27 PM UTC-5, unman wrote:

For posterity sake, this is what worked (please correct me if I'm adding something that is incorrect or potentially dangerous). On sys-firewall, I added this:

sudo iptables -I FORWARD 2 -s 10.137.0.0/24 -d 10.137.0.0/24 -j ACCEPT

Then, on each qube I want to allow network access, I added this:

sudo iptables -I INPUT -s 10.137.0.0/24 -j ACCEPT

It seems to work just fine. Thanks for your help, unman!