Score:1

Intermittent failure connecting SSH/HTTPS to VM Guest running KVM on Ubuntu 20.04 LTS - after sending a ping SSH/HTTPS works

cn flag

first time poster.

Have an odd issue with intermittent failure, connecting to SSH/HTTPS of a guest VM.

How to reproduce issue:

  1. Boot up host and guest, wait a few hours.

  2. SSH/HTTPS into guest from outside, no connectivity.

  3. SSH to guest from host always works.

  4. SSH to host from outside always works

  5. Ping guest from from outside, then SSH/HTTPS to guest from outside, always works

  6. Wait a few hours, then SSH/HTTPS to guest from outside - fails again.

Have tried various things to see if I could find the issue, but none of the proposed "fixes", others have posted, seem to fit my situation and do not work for my issue.

The setup:

Ubuntu 20.04 LTS server with qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst bridge-utils on a physical machine with 2 Network interfaces.

1 bridge interface and 1 interface connected directly.

Bridge interface is used for host and guest, direct interface used for second interface for guest only.

Guest is Debian 11.1 server install

The bridge interface is connected to a standard un-managed switch

Host IP is 192.168.1.26/24 Gateway 192.168.1.254 Guest IP is 192.168.1.27/24 Gateway 192.168.1.254

The directly connected second interface is set to 192.168.10.1/24, no gateway (Used for VLAN).

To ensure that there is no firewall interfering with access to guest, br_netfilter is enabled and the following is loaded:

net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0

Some people indicate that it could be problematic having a host on an IP in the same subnet as the IP of the guest. Do I need to set additional routing entries?

Others suggest ARP issues with MAC addresses.

I have set a fixed MAC addresses using ones from the recommended range. This is required as the upstream from this guest will need to know the MAC address for outbound access control for host and guest.

ip a output on host:

eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5c brd ff:ff:ff:ff:ff:ff
 eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br2 state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5d brd ff:ff:ff:ff:ff:ff
 br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5c brd ff:ff:ff:ff:ff:ff
    inet 169.254.2.83/16 brd 169.254.255.255 scope link noprefixroute br1
       valid_lft forever preferred_lft forever
 br2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.26/24 brd 192.168.1.255 scope global noprefixroute br2
       valid_lft forever preferred_lft forever
 6: macvtap0@br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff
 vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br2 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:e9:15:b2 brd ff:ff:ff:ff:ff:ff

ip route output on host:

default via 192.168.1.254 dev br2 proto static metric 425
169.254.0.0/16 dev br1 proto kernel scope link src 169.254.2.83 metric 426
192.168.1.0/24 dev br2 proto kernel scope link src 192.168.1.26 metric 425
224.0.0.0/4 dev br1 proto static scope link metric 426

ip a output on guest:

 enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global enp1s0
       valid_lft forever preferred_lft forever
 enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 52:54:00:e9:15:b2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.27/24 brd 192.168.1.255 scope global enp2s0
       valid_lft forever preferred_lft forever
 enp1s0.73@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff

ip route output on guest:

default via 192.168.1.254 dev enp2s0 onlink
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.27
192.168.10.0/24 dev enp1s0 proto kernel scope link src 192.168.10.1 

This issue has turned my hair more grey than it was - spent several days reading up on all the possible things I might have missed but have not found anything obvious.

Any pointers would be appreciated.

user535733 avatar
cn flag
"*wait a few hours*:" did you install a Desktop version that perhaps goes to sleep when inactive?
cn flag
No Desktop, server only - surprisingly, there seems to be heaps of people having similar issues but no obvious solution
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.