Unable to access VMs from outside the host

[aljames2]

My guess is you are trying to use firewall rules to force bridge behavior on a NAT configuration. virb0 is the default interface set up when you first install KVM and Libvirt. The default is NAT. It allows your guests to reach the outside world, but they are not seen on the network for inbound traffic.

I suspect you need an actual bridge, br0. This is something you have to set up yourself. Then you attach your VM‘s to that interface. I use Virt Manager when installing VMs & selecting the interface.

My hosts use networkd and a netplan (.yaml) file for configuration. This netplan file is where you define your physical interface and your bridge interface. Alternatively, If you are using Network Manager instead, there is a way to set up a bridge using nmcli commands but I haven’t done that in a while.

The folks on this thread taught me how to do this when I started so I defer to their many years of expertise. I am also not familiar with GNS.

[harshl]

My guess is you are trying to use firewall rules to force bridge behavior on a NAT configuration. virb0 is the default interface set up when you first install KVM and Libvirt. The default is NAT. It allows your guests to reach the outside world, but they are not seen on the network for inbound traffic.

I suspect you need an actual bridge, br0. This is something you have to set up yourself. Then you attach your VM‘s to that interface. I use Virt Manager when installing VMs & selecting the interface.

My hosts use networkd and a netplan (.yaml) file for configuration. This netplan file is where you define your physical interface and your bridge interface. Alternatively, If you are using Network Manager instead, there is a way to set up a bridge using nmcli commands but I haven’t done that in a while.

The folks on this thread taught me how to do this when I started so I defer to their many years of expertise. I am also not familiar with GNS.

Ok, thank you aljames2, I guess I was making a poor assumption that interface virbr0, which was created by default upon install of the OS, would route, not just NAT, since all of the hosts are on the same subnet. Thank you so much for pointing me in this direction in a clear way. I will start looking at making that route, or create a new bridge interface.

Thanks again!

[harshl]

Between the comments from aljames2 and the article linked below, I am in good shape now.

FYI, I found this document TREMENDOUSLY helpful:
https://access.redhat.com/documentat...rk-connections

It points out that the default virbr0 interface provided by libvirt is a NAT interface by default. Which explains why everything could get out, but nothing could get in, even though it was not actually NAT'ing for outbound traffic. The private subnet was seen on my firewall and I had to add a route back to the private subnet via the server host address. {shrug}

For my use case, this lab server sits in an isolated VLAN with the L3 on an NGFW, so I was able to just create a bridge interface, re-IP the management interfaces of my lab into that subnet and I was off to the races. Working great now.

Thanks all.

[TheFu]

Sorry that I wasn't clearer. I've never used virbr0. When I first started doing this on Linux, that wasn't automatically setup, so none of the VMs had any networking if we didn't manually add it. I've seldom had much use for NAT VMs. Makes it hard (impossible) to manage them from my management systems.

The best description I've seen of the possible network configuration options available to a VM is actually in the VirtualBox Networking Chapter (ch 6) of the virtualbox manual. It is worth reading if you haven't done VMs with different networking before.

"Bridged" is a specific type of network. The name, virbr0, is just a name. Don't think it is a bridge. It is not. Bridges connect two sides and are usually invisible. They don't have/need an IP on the bridge at all.

It is common to use the head of the bridge as the VM host IP "holder" too, though that isn't necessary for VMs using the bridge from the other side. Guest VMs don't see or know about the bridge. It is only used in the VM fake/simulated hardware and usually for Linux, we want it to be virtio, not simulate a physical network card like an Intel e1000. virtio isn't speed limited, has lower latency, and lower RAM/CPU overhead than any of the of the NIC choices. Within the same VMhost, virtio bandwidth of 45 Gbps is possible, though it varies wildly. Sometimes I see only 25 Gbps between my VM systems on the same host.

As for firealling, that happens inside the guest VM system, just like it is a physical host. The ufw rules you showed above were for the virbr0 NAT device to prevent it from being a normal bridge. I've never looked closely at it.

Anyway, sorry for the complete miscommunication. Glad you figured it out. Translation isn't always simple.

If I were creating a new VM host today, I'd load 22.04 and setup the bridge on one of the spare NICs in my physical system to be the bridge as outlined at netplan.io/examples Netplan is still maturing, but it has supported bridges well enough for VMs since the fall of 2020. Before then, it had issues for me (or I was too stupid to understand it, hard to tell). 24.04 release date is getting close, but I won't consider making it production use until late July/August. If it was June 2024 and I was forced to bring up a new VM host, I might load 24.04 then. Other considerations would be important, mainly if my "play" 24.04 systems worked well and how many bugs were being reported/fixed weekly in the first few months after the release. I don't need "new". "Stable" is much more important for my needs. We are all different, of course.