search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 47 forks source link

sys-firewall: Failed to parse firewall rules #9119

Open copyvar opened 6 months ago

copyvar commented 6 months ago

How to file a helpful issue

Qubes OS release

4.2

Brief summary

When I do not have a working DSL connection in sys-net, sys-firewall shows Failed to parse firewall rules... message for all VMs with firewall restriction rules enabled.

sys-net is running and logged in DSL router. The error is always for whatever domain I have at the top of the list in the firewall for the VM, like addons.mozilla.org.

Even if I have a working DSL connection after some time, I have to restart all the VMs with firewall restriction rules enabled.

Seems to be similar to https://github.com/QubesOS/qubes-issues/issues/8448

Steps to reproduce

Expected behavior

When DSL connection is established, the VMs should connect to the allowed destinations.

Actual behavior

When DSL connection is established, the VMs DO NOT connect to the allowed destinations.

PS: I can only see half of the message, because the popup dialog does not allow me to copy the message. Where would I find those messages in a log?

3hhh commented 6 months ago

DNS fails with your DSL connection being down, so the firewall rules (which require IPs, not FQDNs) cannot be implemented and everything is blocked.

You should be able to use qvm-firewall --reload on dom0 command line once your DSL connection is up. Alternatively only use IPs in your firewall rules.

Truncating popup dialog messages indicate an issue with your notification daemon (you can install another or reconfigure it). If it's the Qubes OS default notification daemon, that may be a separate issue.

If you want an automated solution, you can currently write a script in dom0 to only start your firewall VMs once the upstream network is up. It may be a good idea to support this in Qubes OS in general, yes.

P.S.: Notification daemon messages aren't logged, yes.

unman commented 6 months ago

I do not think that last suggestion is a good one since many people have a series of proxies, and therefore multiple "firewall VMs". (Any qube which offers network services is a firewall VM.) In many cases they want to be able to start the chain so that they can work in the downstream qubes, even if the network connection is not established. They could not do this if starting the qube was dependent on an upstream net connection.

3hhh commented 6 months ago

On 4/20/24 13:25, unman wrote:

I do not think that last suggestion is a good one since many people have a series of proxies, and therefore multiple "firewall VMs". (Any qube which offers network services is a firewall VM.) In many cases they want to be able to start the chain so that they can work in the downstream qubes, even if the network connection is not established. They could not do this if starting the qube was dependent on an upstream net connection.

Well, it should certainly configurable via e.g. qvm-prefs or qvm-features and there should be some way to override it, e.g. via qvm-start --force.

Most applications (e-mail, chat, browser, ...) with network access / network service qubes only make sense with network access nowadays, i.e. imho it makes sense to provide an option to wait for upstream network access before starting them.

3hhh commented 6 months ago

Thinking about it again, probably the easiest and best (since decentral) solution is to set a 30s retry at /usr/lib/systemd/system/qubes-firewall.service.

Qubes OS should probably do that by default.

copyvar commented 6 months ago

Truncating popup dialog messages indicate an issue with your notification daemon (you can install another or reconfigure it). If it's the Qubes OS default notification daemon, that may be a separate issue.

It's the notification daemon in sys-firewall