<div dir="ltr">On Thu, Jul 23, 2020 at 3:54 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No, don't change it to 0. We need ip_forward enabled as you say.<br></blockquote><div> </div><div>That's what I thought. I'm leaving it as it is. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Correct. The KVM host knows where the <a href="http://10.2.2.1/24" rel="noreferrer" target="_blank">10.2.2.1/24</a> subnet is - it owns<br>
it. The other hosts on your LAN don't know anything about <a href="http://10.2.2.1/24" rel="noreferrer" target="_blank">10.2.2.1/24</a>,<br>
so if they try to access VMs on that subnet, traffic will go to the<br>
default route, aka your LAN router. It then has to know which KVM host<br>
has the <a href="http://10.2.2.1/24" rel="noreferrer" target="_blank">10.2.2.1/24</a> subnet to send the traffic onwards.<br></blockquote><div><br></div><div>Yep, again that's what I thought. For now I'll be leaving it as it is because right now I just need the host to be able to communicate with the VM's. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yep, so that suggests a more fundamental problem with the KVM host<br>
config.<br>
<br>
Since ip_forward is confirmed as set to 1, I feel the most likely problem<br>
is something related to the firewall rules.<br>
<br>
Libvirt will create iptables rules to allow traffic. Tradititionally<br>
this would have been sufficient, in iptables all rules are in the single<br>
set of global tables.<br>
<br>
If your OS distro has enabled "nft" to replace iptables though, things<br>
become more tricky. In nft world there is no single set of global tables.<br>
Any app using nft can define its own top level tables.<br>
<br>
So while libvirt adds iptables rules to allow traffic, there is the<br>
possibility that "nft" rules may none the less deny traffic.<br>
<br>
In the specific case of distros using "firewalld", libvirt does some<br>
further workarounds for this problem.<br>
<br>
Overall though, I'd be investigating your firewall.<br></blockquote><div><br></div><div>Okay, I think I've understood but how can I tell if my distro has 'nft' enabled? Guess I'll ask down at their IRC channel and see if someone can tell me.</div><div>Otherwise I think I'm fried because I googled it and I came out empty handed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is helpful to add logging rules to your firewall immediately before<br>
any REJECT / DROP rules so you can spot packets being dropped. That<br>
combined with tcpdump on the TAP devices should help you confirm<br>
what is happening to traffic.<br></blockquote><div><br></div><div>I don't have the faintest idea on how to set up logging rules, or worst, how to get a tcpdump on my TAP devices and analyse the dump. I'd use wireshark but I wouldn't know what I'd be doing to analyse the dump with it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Often missed is that there are multiple instances of libvirtd. One global<br>
instance that runs as root for privileged set ups, and then one per<br>
user instance that runs unprivileged.<br>
<br>
If you run "virsh" as non-root, you'll be querying the per-user instance.<br>
<br>
virt-manager uses the privileged instance by default.<br>
<br>
Try 'virsh -c qemu:///system netlist' instead, or simply run<br>
virsh as root.<br></blockquote><div><br></div><div>Got it.</div><div>Here's the output with sudo:</div><div><br></div><div>$ sudo virsh net-list <br>[sudo] password for ******: <br> Name State Autostart Persistent<br>--------------------------------------------<br> default active yes yes<br> routed active yes yes<br><br>$ <br>$ virsh -c qemu:///system net-list<br> Name State Autostart Persistent<br>--------------------------------------------<br> default active yes yes<br> routed active yes yes<br><br>$</div><div><br></div><div>This means both network profiles are created, loaded, active and set up for autostart.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks for the headsup. I'll ask the Manjaro guys about the nft. Hopefully they'll know if nft is installed and running.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Rui Correia<br></div></div>