There’s a bug in qubes-firewall.service. It should pull in and be ordered before network-pre.target such that the firewall rules are guaranteed to be in place before the network is raised.
From man sytemd.special,
network-pre.target
This passive target unit may be pulled in by services that want to
run before any network is set up, for example for the purpose of
setting up a firewall. All network management software orders
itself after this target, but does not pull it in.
From Running Services After the Network Is Up
network-pre.target is used to order services before any network interfaces start to be configured. Its primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up. Services that want to be run before the network is configured should use Before=network-pre.target and Wants=network-pre.target.
I suggest applying this change so that people who are currently relying on this popular guide Configuring a ProxyVM VPN Gateway can continue to do so without having to make modifications to systemd themselves.
If you can confirm that this results in a traffic leak, can you
document that here.
Can you also not modify the guide with a warning?
(I’m still not convinced that there is leak in practice. I’ve not on
quick test seen one.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
If you can confirm that this results in a traffic leak, can you
document that here.
I agree that there is not any risk of leak from the AppVMs connected to the VPN NetVM. I had missed that the rules are always run before forwarding is enabled.
I do think there is still an issue, although it is less serious. I’ve explained it on the mailing list, but basically the issue is that the qubes-firewall-user-script can really only be relied upon for forwarding rules, even though it is commonly used for more than forwarding rules. At the very least it should be named appropriately, or a comment included explaning this. I think the better solution is to just order it before network-pre.target as initially suggested.
Custom user firewall rules should not be considered reliable. Please use Qubes OS firewall systems
I wholeheartedly disagree with this. Why are the firewall rules installed by the Qubes firewall systems any more reliable than the firewall rules I create myself?
which puts the firewall rules on the qube’s netvm.
And filter on what? Destination IP? So if the VPN drops then my AppVMs can send packets all the way through my ISP and across the internet, so long as they are addressed to the VPN? That’s not good.
This does provide better protection if the VPN NetVM gets rooted, but if that is a concern then you should be relying on your suggested firewall rules in addition to the rules I’ve suggested, not one or the other.
If you filter by destination IP and port and the VPN goes down, the only allowed traffic is to send data to this IP and port. There is really little issues with this except if you allowed a whole range of IP and that the port used is something like 80/TCP or 443/TCP
Appvm won’t magically leak data, they would have to initiate connections to that combination of IP and port. In practice it never happens, and even if a qube get hacked, I don’t see how this could benefits the attacker.