2

I want to run a qemu-kvm guest with Debian 9 as its OS on a Debian 10 host. The host is connected to the local network, and I would like the guest to be "visible" to the local network as if it were a regular device connected directly to the network. To this end, I configured a bridge named br0 on the host by editing /etc/network/interfaces as follows:

auto lo
iface lo inet loopback

allow-hotplug eth0
auto eth0
iface eth0 inet manual
    up ifconfig eth0 promisc up
    down ifconfig eth0 promisc down

auto br0
iface br0 inet static
    hwaddress ether 08:60:6e:69:4a:b5
    address 192.168.1.11
    netmask 255.255.255.0
    gateway 192.168.1.1

    bridge_ports eth0
    bridge_stp on
    bridge_fd 0

The MAC address configured for the bridge is the same as that of my eth0 interface.

My host's networking seems to work fine after this change.

Using sudo virsh edit debian9 (where debian9 is the name of the guest), I edited the default network interface as follows:

    <interface type='bridge'>
      <mac address='52:54:00:bc:8c:97'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Inside the guest, I assigned a static IP address by editing /etc/network/interfaces as follows, as it did not seem to receive an IP address using DHCP:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug enp1s0
auto enp1s0
iface enp1s0 inet static
    address 192.168.1.13
    netmask 255.255.255.0
    gateway 192.168.1.1

The guest seems to show up correctly in the br0 bridge on the host when I do sudo brctl show:

bridge name     bridge id               STP enabled     interfaces
br0             8000.08606e694ab5       yes             eth0
                                                        vnet0
docker0         8000.024202321e8f       no              veth7291e29
virbr0          8000.5254005aa541       yes             virbr0-nic

The host can now correctly connect to the guest (e.g., using ping or ssh), and the guest can correctly connect to the host, but other devices on the same local network cannot access the guest, or the other way around.

I suspect this must be due to some firewall/routing issue on the host, but am not sure how to diagnose this further. The following is the output of iptables -S on the host. I did not configure any iptables rules myself: most of them are related to libvirt's default NAT network, or a docker installation on the host:

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A DOCKER -d 172.17.0.1/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8050 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

Does anyone have any suggestions as to how I might get the guest to become "visible" on the local network?

0

This happens because FORWARD chain policy is DROP.

You could use

iptables -I FORWARD -i br0 -j ACCEPT
iptables -I FORWARD -o br0 -j ACCEPT

to accept all forwarded traffic from / to br0 interface.

This is also the reason why the client does not get address via DHCP. DHCP packets from the client are dropped by the FORWARD policy.

| improve this answer | |
  • This solved my problem; thanks! – ngj Jun 20 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.