Score:0

Bridged network not forwarding ICMP packets after a small amount of time in Hyper-V Ubuntu 22.04 VM

af flag

I created an Ubuntu 22.04 VM using Hyper-V with the goal of creating a bridged network to act as an unmanaged switch. I'm able to successfully achieve this but after around 5 minutes of inactivity, the ICMP packets just stop getting pushed through the VM.

I have the following setup:

  • A host OS of Windows 11
  • Ubuntu 22.04 VM in Hyper-V
    • Two external network virtual switches which are utilizing USB to Ethernet dongles
      • I did not configure it to allow the management OS to share the network adapters
    • Two network adapters where each adapter is connected to its own external virtual switch
      • I enabled MAC address spoofing on each of these adapters
    • Disabled the firewall with sudo ufw disable
    • iptables and ebtables are both default values (empty)
      • $ sudo iptables -L
        Chain INPUT (policy ACCEPT)
        target     prot opt source               destination
        
        Chain FORWARD (policy ACCEPT)
        target     prot opt source               destination
        
        Chain OUTPUT (policy ACCEPT)
        target     prot opt source               destination
        
      • $ sudo ebtables -L
        Bridge table: filter
        
        Bridge chain: INPUT, entries: 0, policy: ACCEPT
        
        Bridge chain: FORWARD, entries: 0, policy: ACCEPT
        
        Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
        
    • A network bridge br0 with my two external adapters
      • $ brctl show
        bridge name     bridge id               STP enabled     interfaces
        br0             8000.2eb5296c83f2       no              eth1
                                                                eth2
        
      • The bridge and the two adapters are all up
        • $ bridge link show
          3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
          4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19
          

With this configuration, I connected my desktop to one of the physical USB to Ethernet adapters which is a part of my network bridge in the VM, and then I connected a laptop to the other one. They are on the same subnet. I'm able to ping back and forth between the two devices successfully as expected and I can capture the packets on both ends showing the ARP requests/replies followed by the ICMP requests and replies. However, if I leave the VM alone for ~5 minutes and then try to ping the devices again, Wireshark on one of the endpoint devices will show that the ICMP request packet gets a no response found! error. tcpdump on the VM will show that the ARP requests and replies work successfully but doesn't show the expected IP ICMP packet go through which makes me think it's being blocked. Once again, I disabled the firewall and didn't configure iptables or ebtables so I don't know why these packets would get blocked. If I open Control Panel on my host OS that is running the VM and then navigate to the Network Connections page, I can disable and then enable the USB to Ethernet adapters and then ping will work again as expected with the same cycle as before where it will stop working after a small amount of inactivity.

Does anyone know have an idea on what in my pipeline might be causing these issues?

  • USB to Eth adapters?
  • Host OS?
  • Hyper-V configuration?
  • Ubuntu VM configuration?
  • Other?

Packet Captures:

  • Working Ping tcpdump from Ubuntu VM bridge interface (br0):
$ sudo tcpdump -i br0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:42:21.242423 ARP, Request who-has 192.168.1.26 tell 192.168.1.1, length 46
13:42:21.244014 ARP, Reply 192.168.1.26 is-at a4:bb:6d:e9:c3:d8 (oui Unknown), length 46
13:42:21.244331 IP 192.168.1.1 > 192.168.1.26: ICMP echo request, id 10, seq 41376, length 40
13:42:21.246098 IP 192.168.1.26 > 192.168.1.1: ICMP echo reply, id 10, seq 41376, length 40
13:42:22.256799 IP 192.168.1.1 > 192.168.1.26: ICMP echo request, id 10, seq 41385, length 40
13:42:22.258423 IP 192.168.1.26 > 192.168.1.1: ICMP echo reply, id 10, seq 41385, length 40
13:42:23.261432 IP 192.168.1.1 > 192.168.1.26: ICMP echo request, id 10, seq 41407, length 40
13:42:23.263141 IP 192.168.1.26 > 192.168.1.1: ICMP echo reply, id 10, seq 41407, length 40
13:42:24.061881 ARP, Request who-has 192.168.1.21 tell 192.168.1.1, length 46
13:42:24.275445 IP 192.168.1.1 > 192.168.1.26: ICMP echo request, id 10, seq 41431, length 40
13:42:24.276984 IP 192.168.1.26 > 192.168.1.1: ICMP echo reply, id 10, seq 41431, length 40
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
  • Non-Working Ping tcpdump from Ubuntu VM bridge interface (br0):
$ sudo tcpdump -i br0 -v
tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:40:20.560714 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.1, length 46
13:40:20.562439 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.26 is-at a4:bb:6d:e9:c3:d8 (oui Unknown), length 46
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Additional Testing:

  • I ran ping for 10 minutes straight with no issues but once there is a small break, it will stop working until the adapters are reset.
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.