3

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?

1
  • 1
    If you want to know why iptables (working on IP routing: layer 3) affects an Ethernet bridge (Layer 2), check there: serverfault.com/questions/963759/… Commented Jun 21, 2020 at 0:03

1 Answer 1

3

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.

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.