Join Log in
Score:1
avatar Ubuntu

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

in flag
Brandon Staggs

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
46
0 + 0
Doug Smythies avatar
gn flag
Doug Smythies
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.
0
Reply
Doug Smythies avatar
gn flag
Doug Smythies
"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](https://askubuntu.com/questions/1333453/bridged-networking-in-kvm-qemu-lan-addressed-packets-dropped).
0
Reply
in flag
Brandon Staggs
@DougSmythies I have added OS info and iptables output to the question. (Ubuntu Server 20.04.3 LTS, no GUI.)
0
Reply
Doug Smythies avatar
gn flag
Doug Smythies
[This](https://ubuntuforums.org/showthread.php?t=2461631&p=14036896#post14036896) is a write up of how I got it working on my system.
0
Reply
Score:1
avatar Ubuntu
in flag
Brandon Staggs

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.

0 + 0
Doug Smythies avatar
gn flag
Doug Smythies
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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.