Note in firewall settings that denying everything will not affect established connections

[starius]

Qubes OS version (e.g., R3.2):

R3.2

Expected behavior:

When I choose "deny network access except..." without specifying the list of allowed targets, all current connections are dropped.

Actual behavior:

When I choose "deny network access except..." without specifying the list of allowed targets, a current connection continues working.

Steps to reproduce the behavior:

I created ProxyVM based on fedora-23 template and put an AppVM behind it. The ProxyVM had the default firewall rules (allow everything). I established SSH connection from the AppVM and then switched firewall in the ProxyVM to "deny network access except...". The SSH connection was still active, but I can't establish new SSH connections at that point.

Notes:

Current wording in the firewall configuration window is misleading. Either QubesOS should drop all current connections as well or put a big warning message saying that you have to restart all downstream VMs if you really want to block all network access.

[unman]

Your expectations dont match mine.
This is pretty standard behaviour in stateful firewalls. Very few firewalls flush conntrack, so that existing connections are retained after rule changes.

[unman]

Your expectations dont match mine.
This is pretty standard behaviour in stateful firewalls. Very few firewalls flush conntrack, so that existing connections are retained after rule changes.

[andrewdavidwong]

If @marmarek agrees with @unman's assessment, we'll close this as notanissue.

Notes:

• The wording in the firewall config window is misleading only if the expectation is accurate.
• This might be a candidate for an explanatory tooltip (#2211).
• Setting the NetVM to none does seem to have the desired effect.

[andrewdavidwong]

If @marmarek agrees with @unman's assessment, we'll close this as notanissue.

Notes:

• The wording in the firewall config window is misleading only if the expectation is accurate.
• This might be a candidate for an explanatory tooltip (#2211).
• Setting the NetVM to none does seem to have the desired effect.

[marmarek]

This is pretty standard behaviour in stateful firewalls.

This is true, but IMO it should be noted somewhere in the firewall settings. Not everyone configure firewalls daily.

A side note: it is possible to write firewall rules to avoid this effect, at a cost of additional overhead for rules processing (so - every packet passing through firewall). Basically put --ctstate ESTABLISHED -j ACCEPT rule at the end, instead of the beginning. It does not require flushing conntrack on firewall reload (which would interrupt all established connections).

[marmarek]

This is pretty standard behaviour in stateful firewalls.

This is true, but IMO it should be noted somewhere in the firewall settings. Not everyone configure firewalls daily.

A side note: it is possible to write firewall rules to avoid this effect, at a cost of additional overhead for rules processing (so - every packet passing through firewall). Basically put --ctstate ESTABLISHED -j ACCEPT rule at the end, instead of the beginning. It does not require flushing conntrack on firewall reload (which would interrupt all established connections).

[cfcs]

I agree with @starius that the "expected behaviour" should also the desired behaviour.
Otherwise people will get frustrated trying to block something while it appears to have no effect.

When would you want to add a rule you don't want to take effect immediately? Why not just add it later?

IMHO the fact that existing firewall systems have retarded configuration interfaces should not get in the way of making the Qubes UI reliable and consistent.

[cfcs]

I agree with @starius that the "expected behaviour" should also the desired behaviour.
Otherwise people will get frustrated trying to block something while it appears to have no effect.

When would you want to add a rule you don't want to take effect immediately? Why not just add it later?

IMHO the fact that existing firewall systems have retarded configuration interfaces should not get in the way of making the Qubes UI reliable and consistent.

[marmarek]

Updated UI have (in addition) hint that if you want to isolate VM from the network completely, better set netvm to none.

[marmarek]

Updated UI have (in addition) hint that if you want to isolate VM from the network completely, better set netvm to none.

[cfcs]

@marmarek yes, but I believe that if you want to restrict it to x, y, and z only and there's still connections to a and b after you've set this rule, that is counter-intuitive.

[cfcs]

@marmarek yes, but I believe that if you want to restrict it to x, y, and z only and there's still connections to a and b after you've set this rule, that is counter-intuitive.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.9-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.9-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.9-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.9-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update