Qubes firewall script implementation may drop packets

[tasket]

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

R3.1, R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23, debian-8

---

Expected behavior:

When restrictive firewall rules are (re)executed from a script in /rw/config, the firewall state should transition smoothly between former/current restrictive states.

Actual behavior:

Attaching/removing downstream VMs causes iptables to be purged and re-populated in a way that enables the default permissive state (allow forwarding to upstream/eth0) before adding rules from qubes-firewall-user-script (source of restriction).

Steps to reproduce the behavior:

An example script in /rw/config/qubes-firewall-user-script would be:

#/bin/sh
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

Then connect/disconnect downstream appVMs to induce Qubes firewall rebuilding of iptables (while other downstream VMs are transferring packets).

General notes:

Qubes firewall could incorporate a new script from /rw/config that takes the standard iptables-save form... or it might begin the build of each chain with a blanket blocking rule that is removed when qubes-firewall-user-script completes.

---

Related issues:

Issue #1941
Also https://www.qubes-os.org/doc/config-files/

[tasket]

The problem is probably hypothetical, or concerning packet loss (not leaks), or restrictions added to the INPUT chain.

In qubes-firewall, the overall update operation is non-atomic, both iptables update commands are preceded by

echo "0" > /proc/sys/net/ipv4/ip_forward

This prevents leaks for the ProxyVMs primary function, forwarding, but may result in some packets being lost while iptables is updated.

@marmarek : The disabling of ip4_forward in qubes-firewall is open-ended. Would it be advisable to re-enable it at the end of the script to keep the interruption as brief as possible?

[tasket]

The problem is probably hypothetical, or concerning packet loss (not leaks), or restrictions added to the INPUT chain.

In qubes-firewall, the overall update operation is non-atomic, both iptables update commands are preceded by

echo "0" > /proc/sys/net/ipv4/ip_forward

This prevents leaks for the ProxyVMs primary function, forwarding, but may result in some packets being lost while iptables is updated.

@marmarek : The disabling of ip4_forward in qubes-firewall is open-ended. Would it be advisable to re-enable it at the end of the script to keep the interruption as brief as possible?

[unman]

@tasket Look at the start of qubes-firewall where ip_forward is reset:

while true; do
    echo "1" > /proc/sys/net/ipv4/ip_forward

I don't think there is any significant packet loss on firewall updates.

[unman]

@tasket Look at the start of qubes-firewall where ip_forward is reset:

while true; do
    echo "1" > /proc/sys/net/ipv4/ip_forward

I don't think there is any significant packet loss on firewall updates.

[tasket]

@unman : I didn't pick up on the conditions of the loop right away.

There is still the issue of INPUT and OUTPUT rules. If someone has rules to harden INPUT, it will have momentary gaps. Although its not central to the role of a proxyVM, it probably matters in some cases.

[tasket]

@unman : I didn't pick up on the conditions of the loop right away.

There is still the issue of INPUT and OUTPUT rules. If someone has rules to harden INPUT, it will have momentary gaps. Although its not central to the role of a proxyVM, it probably matters in some cases.

[marmarek]

This is already solved in R4.0, by using separate nftable for qubes-firewall. This means:

1. Standard/custom iptables/nftables script no longer needs to worry about qubes-firewall
2. No need to reload custom rules, when qubes-firewall decide to reload anything.

As the issue is minor on R3.2 in the current shape, I'm closing it here.

[marmarek]

This is already solved in R4.0, by using separate nftable for qubes-firewall. This means:

1. Standard/custom iptables/nftables script no longer needs to worry about qubes-firewall
2. No need to reload custom rules, when qubes-firewall decide to reload anything.

As the issue is minor on R3.2 in the current shape, I'm closing it here.