Routed network can't reach outside network

[Rui Correia]

On Mon, Jul 27, 2020 at 9:15 PM Laine Stump <laine at redhat.com> wrote:

> Back in your original message, you said this:
>
>
> On 7/19/20 6:54 AM, Rui Correia wrote:
> > The host can ping the Debian VM and the Debian VM can ping the host but
> > the Debian VM cannot ping the router 10.0.0.1 or any ip address on the
> internet.
>
> But in a later message you say this:
>
> On 7/23/20 10:34 AM, Rui Correia wrote:
>  > But, for testing purposes (trying to reach the VM's from the KVM host)
>  > I don't need those static routes, right? Because right now I'd be ok
>  > if I could reach the VM's from the KVM host and right now I can't.
>
> So which is correct?
>
>
Ouch. Sorry, I see I made a complete mess...
"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.
I can reach the VM's from the KVM host perfectly, so I made a mistake while
typing that message.

>  <forward dev="wlo1" mode="route">
> >    <interface dev="wlo1"/>
> >  </forward>
>
> It will probably make no difference (unless traffic leaving your "KVM
> Host" isn't actually using the interface named "wlo1", and in that case
> it makes *all* the difference!), but I would change this to simply:
>
>    <forward mode='route'/>
>
> The purpose of the "forward dev" is commonly misunderstood as having
> something to do with routine, but it doesn't - it only serves to add an
> iptables rule that will block traffic if it's coming from or going to
> any interface other than (in this case) "wlo1". ie. it's a security
> knob, not a routing knob; if you're not concerned about rogue guests
> then at best it's just creating extra overhead for each packet, and at
> worst it could be blocking traffic if it's misconfigured.
>

Thanks for the thorough explanation. :-)

As for checking with wireshark/tcpdump, mainly the intent is just to
> see, when you send a packet from one end or the other, whether a
> corresponding packet shows up in the output of wireshark/tcpdump. As an
> example, let's say that you are trying to ping (from your original
> diagram) "desktop manjaro" (10.0.0.11) from "debian 10 VM" (10.2.2.10).
> First start a ping in a shell on debian 10 VM", then run a command like
> (as root) this on the KVM Host:
>
>      tcpdump -i virbr2 -n host 10.2.2.10
>
> You should at least see one icmp "echo request" packet for each ping
> that is sent. You might even see an icmp response (and if so, hopefully
> is is an icmp echo reply, rather than destination unreachable or
> something like that).
>
> If you see the outbound icmp echo request and an echo reply, then the
> problem is on your host or in the guest. If you see an echo request but
> no echo reply, then look at the next step out - wlo1 interface on the
> KVM host:
>
>      tcpdump -i wlo1 -n host 10.2.2.10
>
> You should still see the outbound echo request. If not, then again your
> problem is on the KVM host. If you see the echo request, but no reply,
> then you need to go look on "manjaro desktop". Run the same tcpdump
> command there (as root), but replace "wlo1" with whatever is the name of
> the ethernet device on that host connecting it to the network.
>
> At this point you may see an echo request *and* an outgoing echo
> response, but not see that response back at the KVM host. That's when
> you'll want to rerun tcpdump telling it to display the MAC address of
> the packets:
>
>     tcpdump -i <whatever-interface-name> -e -n host 10.2.2.10
>
> Now you can look at the MAC address in the tcpdump output - it should
> contain the MAC of the KVM host, *not* the MAC of your router. If it has
> the MAC of your router, then you haven't added a routing table entry to
> the manjaro desktop's network config. Do that.
>
> (or, possibly you just want to add a route to the router. That will
> work, but will result it a lot of duplicated traffic and ICMP redirect
> packets from the router to the manjaro desktop).
>
> Anyway, there are many paths this can take, but that gives you an idea
> of how to use tcpdump. (you could do the same thing with wireshark, it's
> just a lot more overhead and lots of info when you really need very
> little (and also requires that wireshark be installed and a desktop
> session open, on all the machines involved).
>

Great tips, man! :-D
I'm going to try that.
In the meantime I had to rearrange my lan addresses, due to ISP devices
that don't allow for IP customization...
So here are my latest IP subnets along with the latest tests I've run on
routed network and on NAT.

router - 10.11.11.1
filesrv - 10.11.11.31
kvmhost - 10.11.11.32

NAT'd subnet - 192.168.122.0/24
Routed Network subnet - 10.22.22.0/24

= NAT tests =
VM ip - 192.168.122.147

VM can ping www.google.com
VM can ping 216.58.201.132 (IP address for resolved www.google.com)
VM can ping 192.168.122.1 (NAT vswitch)
VM can ping 10.11.11.1 (router)
VM can ping 10.11.11.31 (filesrv)
VM can ping 10.11.11.32 (kvmhost)

Router cannot ping VM
Filesrv cannot ping VM
KVMhost can ping VM

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.

= Now the real deal: Routed Network =
VM ip - 10.22.22.72

VM cannot ping www.google.com
VM cannot ping 216.58.201.132 (IP address for resolved www.google.com)
VM can ping 10.22.22.1 (NAT vswitch)
VM cannot ping 10.11.11.1 (router)
VM cannot ping 10.11.11.31 (filesrv)
VM can ping 10.11.11.32 (kvmhost)

Router cannot ping VM
Filesrv cannot ping VM
KVMhost can ping VM

Here it fails on letting the VM access the internet.
It also fails on accessing other hosts on the network. Could it have
anything to do with the needed static routes?
Other hosts can't access the VM. Here I understand that it needs the static
routes.

I'll be looking into running some tcpdumps in a couple of days because
right now I'm full of homework...

Thanks for the tips.

Cheers,

Rui Correia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20200728/05028f38/attachment.htm>