No, don't change it to 0.  We need ip_forward enabled as you say.

Correct.  The KVM host knows where the 10.2.2.1/24 subnet is - it owns
it.  The other hosts on your LAN don't know anything about 10.2.2.1/24,
so if they try to access VMs on that subnet, traffic will go to the
default route, aka your LAN router. It then has to know which KVM host
has the 10.2.2.1/24 subnet to send the traffic onwards.

Yep, so that suggests a more fundamental problem with the KVM host
config.

Since ip_forward is confirmed as set to 1,  I feel the most likely problem
is something related to the firewall rules.

Libvirt will create iptables rules to allow traffic. Tradititionally
this would have been sufficient, in iptables all rules are in the single
set of global tables.

If your OS distro has enabled "nft" to replace iptables though, things
become more tricky. In nft world there is no single set of global tables.
Any app using nft can define its own top level tables.

So while libvirt adds iptables rules to allow traffic, there is the
possibility that "nft" rules may none the less deny traffic.

In the specific case of distros using "firewalld", libvirt does some
further workarounds for this problem.

Overall though, I'd be investigating your firewall.

It is helpful to add logging rules to your firewall immediately before
any REJECT / DROP rules so you can spot packets being dropped. That
combined with tcpdump on the TAP devices should help you confirm
what is happening to traffic.

Often missed is that there are multiple instances of libvirtd. One global
instance that runs as root for privileged set ups, and then one per
user instance that runs unprivileged.

If you run "virsh" as non-root, you'll be querying the per-user instance.

virt-manager uses the privileged instance by default.

Try   'virsh -c qemu:///system netlist' instead, or simply run
virsh as root.