How can guest VMs reach the host on the network with bridged networking?

Question

After asking this question I was able to configure my virtual machines to connect directly the LAN. This worked as intended, except that the guest VMs cannot communicate with the host.

Ubuntu Server 20.04.03 LTS.

Here is my host netplan:

network:
  ethernets:
    enp3s0:
      dhcp4: true
      optional: true
    enp4s0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces:
      - enp4s0
      addresses:
      - 192.168.1.200/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
        - 1.1.1.1
        - 1.0.0.1
        - 8.8.8.8
        - 8.8.4.4
        search: []
      parameters:
        stp: true
      dhcp4: no
      dhcp6: no
  vlans:
    vlan15:
      accept-ra: no
      id: 15
      link: enp4s0
  version: 2

And here is the vm network configuration (virsh net-edit default)

<network>
  <name>default</name>
  <uuid>e0235996-534d-49c8-94d6-f213acd1552e</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

While the guest VM appears on the LAN and has outside access, and can be reached from other real computers on the network, the guest VM is unable to reach its host.

Here is the output from the Windows Server command prompt in the VM for a ping and tracert: (the host is 192.168.1.200, the guest is 192.168.1.33, which it got from the router's DHCP on the LAN)

C:\Users\Administrator>ping 192.168.1.200
Pinging 192.168.1.200 with 32 bytes of data:
Reply from 192.168.1.33: Destination host unreachable.
Ping statistics for 192.168.1.200:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
C:\Users\Administrator>tracert 192.168.1.200
Tracing route to 192.168.1.200 over a maximum of 30 hops
1  SVR-BACKUP [192.168.1.33]  reports: Destination host unreachable.
Trace complete.

What else do I need to do to complete the connectivity, so that the guest VMs can communicate with the host?

Edit: as requested, here is output of sudo iptables -xvnL

Chain INPUT (policy ACCEPT 195866 packets, 25432549 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
       0        0 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT 252563 packets, 775126408 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain DOCKER (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:3690
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
       0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
       0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain DOCKER-USER (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

And sudo iptables -t nat -xvnL

Chain PREROUTING (policy ACCEPT 39583 packets, 13257450 bytes)
    pkts      bytes target     prot opt in     out     source               destination
    8156  2476484 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT 8712 packets, 2524965 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 10911 packets, 606007 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       6     1768 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 10911 packets, 606007 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
       0        0 MASQUERADE  tcp  --  *      *       172.17.0.2           172.17.0.2           tcp dpt:3690
Chain DOCKER (2 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0
       0        0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3690 to:172.17.0.2:3690

Is your host Ubuntu 20.04 a server (no GUI) or a desktop? I ask because I want to know if you are using network manager or networkd as the renderer. The references you have used might not be current for Ubuntu 20.04, and do differ from what I do. ping works for me. I have a server (no GUI) and use networkd as the renderer. It'll be a few days before I would have time to write another answer to your original question. — Doug Smythies, Feb 04 '22 at 16:18
"The host firewall is not active." Are you sure? What do you get for sudo iptables -xvnL and sudo iptables -t nat -xvnL? No rules at all is what I have, and which was an objective, as I want independent control of the iptables rule set for other testing. See also some of my past troubles. — Doug Smythies, Feb 04 '22 at 16:41
@DougSmythies I have added OS info and iptables output to the question. (Ubuntu Server 20.04.3 LTS, no GUI.) — Brandon Staggs, Feb 04 '22 at 16:56

score 1 · Accepted Answer · answered Feb 05 '22 at 23:03

The issue was netfilter.

Following the instructions here I disabled netfilter for bridges and was able to get proper network communication between VMs, the LAN, and the host. The relevant portion:

For performance and security reasons, disable netfilter for bridges. Create /etc/sysctl.d/bridge.conf with these contents:
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0
Create /etc/udev/rules.d/99-bridge.rules with the following contents. This udev rule applies the sysctl settings above when the bridge module is loaded. (If using Linux kernel 3.18 or later, change KERNEL=="bridge" to KERNEL=="br_netfilter".)
ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/sbin/sysctl -p /etc/sysctl.d/bridge.conf"

After doing so, all of my problems are gone.

Thanks for coming back with your own answer. My system works fine without your answer. I think the difference between us it that IPV6 is disabled on my system. — Doug Smythies, Feb 06 '22 at 15:55

How can guest VMs reach the host on the network with bridged networking?

1 Answers1

Linked