KVM bridge not routing guests to host

Ask Fedora Ask in English
,
1

First off, I apologize if this is not the best place to ask this question. I’m not really sure where to post it, but this community has been great so far. I hope someone here wouldn’t mind helping me out a bit. :slight_smile:

I’m having a bit of trouble with my KVM network. I expect it is due to my lack of knowledge (networking really isn’t my strong suit), and not so much an error.

The problem I’m having is that my guests cannot access my host through the bridge, but they can access the host externally. So I guess I need to re-configure the bridge, but I really have no idea how to do that.

I read up on a few things, and I’m seeing recommendations that the physical interface needs to have no IP address set. However, if I do this, I won’t be able to access the internet from the host, as it has no external IP. I could do this by adding another NIC, but I don’t have one handy, and I’m running low on expansion slots on my motherboard.

Is there a way to have a proper, or at least working, software bridge for my VMs on one physical interface? It “works” using external traffic, but that’s a lot of extra and unnecessary steps, which has all kinds of concerns including security.

I’m not sure why external traffic works but internal traffic doesn’t when it is all going across the same interfaces. It sounds to me like it is a routing problem, but I really don’t know how to set up routing on a virtual bridge like this.

Any info or assistance would be appreciated, even if it is just a link to somewhere else for me to read up and understand what is going on more clearly.

Thanks in advance!

2

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_virtualization/index#comparison-of-virtual-machine-connection-types_types-of-virtual-machine-network-connections

I’m not sure if I have understood your current setup, but it seems that you are running in private mode.
Do you have a subnet? A 192.168.122.0/24 is normally created by default.

3 Likes
3

On mine using KVM/QEMU My VMs are able to communicate with the host and the world. I always set the network to bridging using virbr0 when I create the vm (the default is NAT). The address assigned is from the 192.168.122.0/24 net and I can connect both ways between the host and the VM. The host uses nat to forward communications from the VM to the world.

I did have to set a route in my gateway router so other machines on my local network could talk to the VMs.

1 Like
4

Thank you, that document looks like some good reading material! :slight_smile:

1 Like
5

That’s interesting. Thank you for sharing your experience.

I believe I have the same 192.168.122.0/24 net set up. I did change it to a different network, but I couldn’t get it to work right, so I changed it back… but it still isn’t working right.

I’ve made a few changes, and interestingly, it is less broken now. One change is that there have been multiple reboots over the course of the weekend.

Another change is that I got rid of my physical router, because it was causing me grief with port forwarding. I plan to replace it, but haven’t gotten around to it yet.

What I meant before about “internal” vs “external” access is that if I try to ping the IP of the host on the inside of the physical router’s network (192.168.0.101), it would time out. However if I tried pinging the DNS name, which resolved to the router’s IP, then it would work.

I guess this makes sense, as the 192.168.122.0/24 network cannot access the 192.168.0.0/24 network directly. However, I expected the software bridge to translate from one network to the other, to avoid pushing the traffic off the host machine. It seems like a potential security risk to do so.

So, now my concern is that it seems like the software bridge is pushing the internal traffic (from guest to host) out to my ISP and back, which is not what I want. Is this correct? If so, is there a way to stop it?

Effectively, I want them on the same network, but the VM refused to boot when I tried doing this. I’m getting pretty tired of software like this telling me what I can and can’t do. I’m the system administrator, not the software developers. I appreciate security, but not authoritarianism.

6

You should post the relevant configs for diagnostics, otherwise it’s confusing.
https://discussion.fedoraproject.org/t/virt-manager-nic-link-state-set-to-down-but-guest-network-still-connected/70358/6?u=vgaetera

7

Sorry you find it confusing.

I’m not sure why, but it is working properly now. :upside_down_face:

I was able to ping the host from the guest without an external (ISP) connection.

1 Like
8

What do you now have as a router? You said you removed the external router so something is acting as the gateway router. If it is your host running the VMs then that solves the routing for the entire local network on the 192.168.0.0 LAN to access the VMs because that host would automatically have the route to the 192.168.122.0 network.

And, no, your conjecture that having the route on your gateway router to redirect traffic from the 192.168.0.0 network going to the 192.168.122.0 net to the host running the VMs does not send traffic out to your ISP. It stays on the local LAN. In fact the ISP would not know where to send that traffic since it is a non-routable net address.

9

Well when I remove the physical router, I don’t have one. I’m not sure what you mean by this question.

Yes, the host should route the traffic to the VMs, but as I said, it wasn’t working correctly. I had to use my public IP, which should have resolved to loopback, but it didn’t seem too. Something was obviously broken on the host.

My ISP would have routed it back to me, given I was using my own address, and not the 192.168.122.0/24 net.

10

My understanding then is that you only have one machine and it is directly connected to the ISP node. Previously it was connected through your router to the ISP.

IIUC then with the router connected the host sent packets for the 122 net to the router, which had no knowledge of where to route them so they were dropped. Now the host sends packets directly to the VM via the bridge since it has no intervening router to talk to.

before:
host → router (dropped since there was no route)
now:
host → tries main interface (default route) and sees no route, looks at bridge and forwards there

This or something similar is what is happening. The intermediate step with no route (and its delay) can be removed by simply adding on the host a route to the 192.168.122.0/24 net to be directed at the 192.168.122.1 address of the virbr0 interface. Adding a route on the host will prevent even trying the default route and keep all traffic internal to the host.

1 Like
11

Thanks for the additional information. I’ll be sure to set up a route on the host directly if I have any more trouble with that.

With the exception of the physical router, everything seems to be working fine now.

I really don’t understand why I get “connection refused” with the router, but not without it. Even with the router, the port is listed as “open” by external port scanners and I see the traffic come through with tcpdump.

I verified that it is the same behaviour under Windows, so it isn’t a problem with Fedora specifically. I just don’t understand what the problem is, so I can’t fix it.

12

The answer is simply one word. “routing”

By default everything follows the default route, which points to the router, which then does not know what to do with packets addressed to 192.168.122.0/24 so they get dropped. A routing table entry in the router fixes that so the router knows to send the packets to the VM host.
The host itself, with a bridge address of 192.168.122.1 still does not necessarily know to route packets to (for example) 192.168.122.66 via the 192.168.122.1 interface unless a routing table entry has been made, although as you have seen, sometimes the host sees the addresses for the VM hosts as local on that interface so it works. The VM host should not be confused that way, but sometimes it does not work as expected.

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.