On Sat, Aug 22, 2020 at 02:01:54AM -0700, 54th Parallel wrote:
> On Friday, 21 August 2020 at 16:58:48 UTC+8 54th Parallel wrote:
> 
> > I'm having the same issue with disposable firewalls built on 
> > debian-10-minimal, with the minimum amount of packages, on 
> > brand-spanking-new installations (plural) being unreliable firewalls. They 
> > sometimes function but not all the time--and this is what's scary, because 
> > there's no way of knowing without manually checking all the time. The 
> > warning prompts when editing firewall rules aren't useful indicators since 
> > they always appear regardless of whether filtering is happening.
> >
> > I ran systemctl in both and found that qubes-firewall.service is not 
> > running in either, despite having manually activated them. I'm not a 
> > technical person, but this seems like a pretty critical issue to me 
> > (unreliable firewall with no indicator)--a warning about using minimal 
> > debian as templates for firewalls should be put up somewhere highly visible.
> >
> > This unreliability has been bugging me for a while and I've been testing 
> > and testing (to the best of my abilities) before realizing that this is 
> > almost certainly not a user issue, so Sven, the OP,  probably either ran 
> > into the issue again, didn't know about his deactivated firewalls, or 
> > didn't report the issue. 
> >
> 
> After some more probing around, I think I've found the issue, and that what 
> I wrote earlier contains inaccuracies. The unreliable firewall might not be 
> a debian-10-minimal issue, though the warning prompt that appears whenever 
> editing firewall rules in a connected VM is. 
> 
> My setup has two firewalls--one behind sys-net and another behind a VPN VM. 
> Though the two firewalls are clones of one another, the sys-net firewall 
> works (responds to rules set in appVMs) and the proxyVM firewall doesn't. 
> This is what caused me to think that deb-10-min firewalls in general are 
> unreliable--some things are connected to the net-firewall (sometimes) and 
> most are connected to the VPN-firewall. This makes it look like the 
> firewalls work sometimes. 
> 
> I have two laptops running Qubes with the same setup. Of the four 
> firewalls, all with qubes-firewall explicitly enabled, only one actually 
> has the qubes-firewall.service show up after typing 'systemctl | grep 
> firewall'. Each of these firewalls were created in fresh but updated 
> installations of 4.0.3 with the absolute minimum amount of packages 
> (qubes-core-agent-passwordless-root (so I can configure sudo prompt), 
> qubes-core-agent-networking, apparmor*) and the typical settings, along 
> with qubes-vm-hardening (vm-boot-protect enabled).
> 
> Any insight into this would be greatly appreciated since this is a massive 
> headache for me.
> 

To deal with the question here, I use debian minimal templates
extensively, (NOT with qubes-vm-hardening), and have never seen this
issue - neither the unreliable firewall nor the warning prompts issue.
I've asked fellow users who also use debian-minimal and they do no not
recognise the issue.
So either it's qubes-vm-hardening, or your proxyVM setup.
Insight will follow (perhaps) if you give more information. How have you
set up the proxyVM? Since that does not work n either machine we should
be able to dig into that problem relatively easily.
What is different about the setup and laptop where the "sys-net
firewall" (please explain what this means) does NOT work compared to the
one where it DOES work?

For the sake of sanity I suggest you answer in ONE place and then
cross-post the solution, rather than pursue the issue in both the
forum and the mailing list. And please don't post it in reddit too.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200822151042.GB29426%40thirdeyesecurity.org.

Reply via email to