0

Summary: VMs on host in different subnets can reach each other, but VM on subnet B cannot contact host's interface on subnet A. I am not sure if this is a product of my lab setup and firewall rules, or something in libvirt/KVM networking.

Disclaimer: this VM host is actually a VM itself, with its external interfaces being virbrX interfaces with forward mode=route, but I don't think this is the issue, as most of the VMs can communicate fine. That said...

The VM host has two interfaces. Subnet A: 192.168.122.10 and 192.168.130.10. routing looks like this:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.130.0   0.0.0.0         255.255.255.0   U     0      0        0 br1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         192.168.122.1   0.0.0.0         UG    0      0        0 br0

VMs (all on this host) on 122 can connect to VMs (all on this host) on 130, and vice versa. However, when a VM on 122 tries to connect to the HOST on 130.10, or when a VM on 130 tries to connect to 122.10, pings don't work, and connections time out.

Doing a TCP dump on the host shows that the packets are getting to the host, but no packets are getting back to the VM. I see this, for example:

23:18:24.111043 IP mailserver-a.kugler.localdomain.34642 > 
vmserver-a.kugler.localdomain.ssh <packet information here>

Of course, I don't see any return packet, nor even an attempt to return packets. There are no iptables rules that would be blocking (no rules, all default accept). What am I missing? Why are all cross-subnet connections working, except when I try to do that to connect to the VM host?

Thanks for any insight.

1 Answers1

0

Thinking about this some more, I realized that it probably had to do with the reply trying to go over the 130.10 interface. I set that interface to another RFC private subnet 172.16.x.x that I wasn't using, and restarted networking. Just like that, 130.x hosts could connect to the 122.10 address.

That is fine, because in production, the second interface won't even have a valid IP address, it will just serve as a bridge interface for VMs that need to be on that physical network.