Systemctl in sys-firewall tells me qubes-firewall.service is "loaded
active running", if that helps.
--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots
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.
On 22. Aug 2020, at 11:01, 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.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4ce48a47-2bec-4d61-a855-5ef83b61d1f9n%40googlegroups.com.
I am not sure what you mean with „behind a vpn vm“.My setup is such that I have the sys-net VM which is used as network vm in sys-firewall and a few sys-vpn-xxx. sys-firewall in turn is used as network vm for all app VMs that connect directly to the internet and the sys-vpn-xxx VMs are used by various VMs that connect through the various VPNs. There is no need for extra proxy or firewall VMs, since the sys-vpn-xxx can themselves double as firewall VMs, since they are proxy VMs already. Therefore any rules specified in any of the app VMs (no matter if directly connected through sys-firewall or indirectly through a vpn) are taken care of by the network vm they are connected to. And I have never had a problem with this setup. At least none, that I am aware of. ;-)
Also don’t forget, that a proxy vm set as network vm for your sys-vpn, will never see anything other than the sys-vpn connecting to your vpn provider’s server. Therefore any rules specified in your sys-vpn are pretty much useless.