<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 9:15 PM Laine Stump <<a href="mailto:laine@redhat.com" target="_blank">laine@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Back in your original message, you said this:<br> <br> <br> On 7/19/20 6:54 AM, Rui Correia wrote:<br> > The host can ping the Debian VM and the Debian VM can ping the host but<br> > the Debian VM cannot ping the router 10.0.0.1 or any ip address on the internet.<br> <br> But in a later message you say this:<br> <br> On 7/23/20 10:34 AM, Rui Correia wrote:<br> > But, for testing purposes (trying to reach the VM's from the KVM host)<br> > I don't need those static routes, right? Because right now I'd be ok<br> > if I could reach the VM's from the KVM host and right now I can't.<br> <br> So which is correct?<br> <br></blockquote><div><br></div><div>Ouch. Sorry, I see I made a complete mess...</div><div>"because right now I'd be ok if I could reach the VM's from the KVM host and right now I can't" -> this is not true.</div><div>I can reach the VM's from the KVM host perfectly, so I made a mistake while typing that message.<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"> > <forward dev="wlo1" mode="route"><br> > <interface dev="wlo1"/><br> > </forward><br> <br> It will probably make no difference (unless traffic leaving your "KVM <br> Host" isn't actually using the interface named "wlo1", and in that case <br> it makes *all* the difference!), but I would change this to simply:<br> <br> <forward mode='route'/><br> <br> The purpose of the "forward dev" is commonly misunderstood as having <br> something to do with routine, but it doesn't - it only serves to add an <br> iptables rule that will block traffic if it's coming from or going to <br> any interface other than (in this case) "wlo1". ie. it's a security <br> knob, not a routing knob; if you're not concerned about rogue guests <br> then at best it's just creating extra overhead for each packet, and at <br> worst it could be blocking traffic if it's misconfigured.<br></blockquote><div><br></div><div>Thanks for the thorough explanation. :-)<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"> As for checking with wireshark/tcpdump, mainly the intent is just to <br> see, when you send a packet from one end or the other, whether a <br> corresponding packet shows up in the output of wireshark/tcpdump. As an <br> example, let's say that you are trying to ping (from your original <br> diagram) "desktop manjaro" (10.0.0.11) from "debian 10 VM" (10.2.2.10). <br> First start a ping in a shell on debian 10 VM", then run a command like <br> (as root) this on the KVM Host:<br> <br> tcpdump -i virbr2 -n host 10.2.2.10<br> <br> You should at least see one icmp "echo request" packet for each ping <br> that is sent. You might even see an icmp response (and if so, hopefully <br> is is an icmp echo reply, rather than destination unreachable or <br> something like that).<br> <br> If you see the outbound icmp echo request and an echo reply, then the <br> problem is on your host or in the guest. If you see an echo request but <br> no echo reply, then look at the next step out - wlo1 interface on the <br> KVM host:<br> <br> tcpdump -i wlo1 -n host 10.2.2.10<br> <br> You should still see the outbound echo request. If not, then again your <br> problem is on the KVM host. If you see the echo request, but no reply, <br> then you need to go look on "manjaro desktop". Run the same tcpdump <br> command there (as root), but replace "wlo1" with whatever is the name of <br> the ethernet device on that host connecting it to the network.<br> <br> At this point you may see an echo request *and* an outgoing echo <br> response, but not see that response back at the KVM host. That's when <br> you'll want to rerun tcpdump telling it to display the MAC address of <br> the packets:<br> <br> tcpdump -i <whatever-interface-name> -e -n host 10.2.2.10<br> <br> Now you can look at the MAC address in the tcpdump output - it should <br> contain the MAC of the KVM host, *not* the MAC of your router. If it has <br> the MAC of your router, then you haven't added a routing table entry to <br> the manjaro desktop's network config. Do that.<br> <br> (or, possibly you just want to add a route to the router. That will <br> work, but will result it a lot of duplicated traffic and ICMP redirect <br> packets from the router to the manjaro desktop).<br> <br> Anyway, there are many paths this can take, but that gives you an idea <br> of how to use tcpdump. (you could do the same thing with wireshark, it's <br> just a lot more overhead and lots of info when you really need very <br> little (and also requires that wireshark be installed and a desktop <br> session open, on all the machines involved).<br></blockquote><div> </div><div>Great tips, man! :-D</div><div>I'm going to try that.</div><div>In the meantime I had to rearrange my lan addresses, due to ISP devices that don't allow for IP customization...</div><div>So here are my latest IP subnets along with the latest tests I've run on routed network and on NAT.</div><div><br></div><div>router - 10.11.11.1<br>filesrv - 10.11.11.31<br>kvmhost - 10.11.11.32</div><div><br></div><div>NAT'd subnet - <a href="http://192.168.122.0/24">192.168.122.0/24</a></div><div>Routed Network subnet - <a href="http://10.22.22.0/24">10.22.22.0/24</a></div><div><br></div><div>= NAT tests =</div><div>VM ip - 192.168.122.147</div><div><br></div><div>VM can ping <a href="http://www.google.com">www.google.com</a></div><div>VM can ping 216.58.201.132 (IP address for resolved <a href="http://www.google.com">www.google.com</a>)</div><div>VM can ping 192.168.122.1 (NAT vswitch)</div><div>VM can ping 10.11.11.1 (router)</div><div>VM can ping 10.11.11.31 (filesrv)</div><div>VM can ping 10.11.11.32 (kvmhost)</div><div><br></div><div>Router cannot ping VM</div><div>Filesrv cannot ping VM</div><div>KVMhost can ping VM</div><div><br></div><div>So, it went as expected in a NAT environment. The VM can go out freely but inboud traffic gets caught up by NAT except for when it comes from the KVM host.</div><div><br></div><div>= Now the real deal: Routed Network =</div><div>VM ip - 10.22.22.72</div><div><br></div><div><div>VM cannot ping <a href="http://www.google.com">www.google.com</a></div><div>VM cannot ping 216.58.201.132 (IP address for resolved <a href="http://www.google.com">www.google.com</a>)</div><div>VM can ping 10.22.22.1 (NAT vswitch)</div><div>VM cannot ping 10.11.11.1 (router)</div><div>VM cannot ping 10.11.11.31 (filesrv)</div><div>VM can ping 10.11.11.32 (kvmhost)</div><div><br></div><div>Router cannot ping VM</div><div>Filesrv cannot ping VM</div><div>KVMhost can ping VM</div><div><br></div><div>Here it fails on letting the VM access the internet.</div><div>It also fails on accessing other hosts on the network. Could it have anything to do with the needed static routes?</div><div>Other hosts can't access the VM. Here I understand that it needs the static routes.</div><div><br></div><div>I'll be looking into running some tcpdumps in a couple of days because right now I'm full of homework...</div><div><br></div><div>Thanks for the tips.</div><div><br></div><div>Cheers,</div><div><br></div><div>Rui Correia<br></div></div></div></div>