Per-guest firewall

Why the host is off limits

Every firewall interface that can edit the host's rules can also, on a bad afternoon, close the port you are sitting on. Then the machine is fine, the service is fine, and nobody can get in to fix it.

So the host's ruleset is a read-only view here. It is worth showing — a rule further up can explain why a guest is unreachable — but it is not worth editing from a browser session that the same rule might end.

The same rules for both kinds of guest

A VM and a container get the same rules. The way to the device differs: for a VM the filter is entered into the interface of its libvirt domain and applied when it starts; a container is not a libvirt domain, so the filter is bound straight to the host-side veth device.

Such a binding lives only as long as the device — it disappears when the container stops, and the start puts it back. That is handled rather than left to the operator to remember.

What it becomes underneath

libvirt turns the filters into ebtables and iptables rules. A filter that a running guest is using and that is defined anew is followed immediately; only attaching one for the first time needs the device updated or the binding set.

A catch-all rule needs its connection state written out, and DHCP needs its two UDP ports named explicitly — a rule set that only allows “established” traffic will let a guest run and never let it get an address.

Where the filter is not in the way

Traffic from the host itself to a guest does not pass this filter. It never leaves the host's own stack, so there is nothing on a device for the rule to sit on.

That is said here rather than discovered later: a check that works from the host does not prove that anything else on the network can reach the guest.