I’m trying to move my system qubes (sys-net, sys-firewall, VPN) from debian-13-minimal to Kicksecure 18 on Qubes 4.3. I keep hitting the same wall and I’d like to know whether this is expected behaviour or whether I’m missing something.
The symptom. In an AppVM based on Kicksecure, DNS resolves fine, the interface is up, the default route is there. But any outbound TCP connection is refused immediately: Connection refused, not a timeout. I tried several different hosts, same result every time.
What I did to rule out my own setup.
I tried two different installation paths. First, the ready-made kicksecure-18 template from the community repo. Second, distro-morphing: I took my working debian-13-minimal (with qubes-core-agent-networking, network-manager and firmware - it’s the template my working sys-net runs on) and installed kicksecure-qubes-cli on top of it. The result was identical both times.
Control: an AppVM on that same debian-13-minimal, same NetVM, same conditions - outbound TCP works without trouble. So exactly one variable changes.
Inside the Kicksecure qube, nft list tables shows only ip qubes and ip6 qubes, i.e. the standard Qubes tables and nothing else. whonix-firewall is inactive.
So my question: what is refusing outbound connections? Is this a Kicksecure protection that has to be configured explicitly for network-facing qubes, or is it a mistake in how I built this? I found a few threads with the same symptom but none of them ended in an answer.
I’d also like to know whether anyone is running Kicksecure specifically as sys-net or sys-firewall, rather than for app qubes. If so, what did you have to change to make it work?
I have no experience of trying Kicksecure, but in the past I’ve found useful info about required packages in the docs for minimal templates:
I do not remember needing to mess with (edit: iptables came from somewhere) nftables, but that would be my next thing to search for in the logs/journal…
I have no experience with Kicksecure out of Whonix. What I would try for a start is to flush the whole nft ruleset in the K-based sys-net and test outbound connection there. This will tell me if it is nft-related or not.
I would also compare the enabled/running systemd units of Debian and Kicksecure. Stock Debian starts newly installed services immediately. Kicksecure may have been hardened against this and may use additional preset disabling, so explicit enabling of some network-related service may be required. (just a speculation)
If you are experienced with Linux, i would choose Debian minimal far over Kicksecure for sys-net. Kicksecure is amazing for browsing VMs etc, but some sysctl and other hardening will conflict with firewall and sys-net and it can change on updates, so not stable for that job. A Debian minimal can be hardened as Kicksecure and you can make sure it will not conflict.
@qubist@tommy thanks for the pointers - I tested both, here is the outcome.
The main thing: I could not reproduce the problem, and the cause was on my side. The test qube was attached to a netvm that had no working uplink, and that is where the instant connection refused came from. With a working netvm the Kicksecure qube reaches the outside exactly like the Debian minimal control does.
I had checked qubist’s suggestion first: flushing the whole nft ruleset changed nothing, which makes sense now - the rules were never the issue. Comparing enabled systemd units turned out not to be necessary.
So I am withdrawing the question: Kicksecure as a network qube does not refuse outbound connections. Apologies for the noise. I will leave the post-mortem here in case it saves someone an evening - connection refused after 0 ms with an empty nft ruleset is a reason to check the netvm uplink, not the template.
tommy, your point about hardening that shifts across updates still settles it for me against Kicksecure in the sys-net role, so my system qubes stay on Debian minimal. Do you have recommendations on which hardening for minimal in that role is actually worth doing?
On the motivation, in case it comes up: I am cutting the number of templates because my system disk is a removable encrypted volume, and both its size and the time to bring it up are limited. The price of keeping a second family - Debian minimal only for the system qubes, with the app qubes on Kicksecure - is roughly one minimal base, about 2.3 GB permanently. That is a measured figure rather than the sum of the clones: in a thin pool the clones share blocks with the base.