1

I’m encountering a network issue on my Debian 12 Server where activating any virtual network device — such as when starting Docker or initiating a VM with qemu-kvm — results in the new virtual device taking over the default network route. This change disrupts my external network connection, causing a loss of internet access. Usually, the connection persists after starting the services for around 30 to 40 seconds, upon which the output from ip route show changes from:

default via 192.168.178.1 dev enp4s0
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.1 dev enp4s0 scope link

to either this when starting a docker container with default network rules:

0.0.0.0 dev veth0136027 scope link
default dev veth0136027 scope link
default via 192.168.178.1 dev enp4s0
169.254.0.0/16 dev veth0136027 proto kernel scope link src 169.254.214.10
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.0/24 dev veth0136027 proto kernel scope link src 192.168.178.20
192.168.178.1 dev enp4s0 scope link

or this when starting a vm via qemu-kvm:

0.0.0.0 dev vnet2 scope link
default dev vnet2 scope link
default via 192.168.178.1 dev enp4s0
169.254.0.0/16 dev vnet2 proto kernel scope link src 169.254.251.24
172.30.0.0/16 dev br-036d78a9f36a proto kernel scope link src 172.30.0.1 linkdown
172.31.0.0/24 dev docker0 proto kernel scope link src 172.31.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.10
192.168.178.0/24 dev vnet2 proto kernel scope link src 192.168.178.20
192.168.178.1 dev enp4s0 scope link

upon which both ping google.com and ping 8.8.8.8 return

From 192.168.178.20 (192.168.178.20) icmp_seq=35 Destination Host Unreachable and

From 192.168.178.20 icmp_seq=36 Destination Host Unreachable

respectively.

The logs from sudo journalctl -xeu systemd-networkd are the following:

Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Failed to start LLDP client: No such device
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Could not process link message: No such device
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Failed
Aug 03 14:27:41 callisto systemd-networkd[873]: veth5f934f0: Link DOWN
Aug 03 14:27:41 callisto systemd-networkd[873]: veth5f934f0: Lost carrier
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Link DOWN
Aug 03 14:27:41 callisto systemd-networkd[873]: veth0d1746b: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: docker0: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link DOWN
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Lost carrier
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: DHCPv6 lease lost
Aug 03 14:38:37 callisto systemd-networkd[873]: vethff4269b: Link DOWN
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Link UP
Aug 03 14:38:37 callisto systemd-networkd[873]: veth67c6d92: Gained carrier
Aug 03 14:38:38 callisto systemd-networkd[873]: docker0: Lost carrier
Aug 03 14:38:39 callisto systemd-networkd[873]: veth67c6d92: Gained IPv6LL
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: Lost carrier
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: DHCPv6 lease lost
Aug 03 14:42:32 callisto systemd-networkd[873]: veth67c6d92: Link DOWN

Things I have already tried include:

  • Setting my /etc/network/interfaces configuration to the following:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp4s0
iface enp4s0 inet static
    address 192.168.178.10
    netmask 255.255.255.0
    gateway 192.168.178.1
    dns-nameservers 100.100.100.100

# This is an autoconfigured IPv6 interface
iface enp4s0 inet6 auto
  • Switching from the default NetworkManager to systemd-networkd with the following configuration:
# /etc/systemd/network/10-enp4s0.network
[Match]
Name=enp4s0

[Network]
Address=192.168.178.10/24
Gateway=192.168.178.1
DNS=100.100.100.100
Priority=100
  • Deleting the new routes manually, which worked but is not a practical solution
  • Disabling my ufw firewall, to see if it makes any kind of difference (it didn't)

Please excuse any stupid mistakes or gaps in knowledge on my part, I am tinkering with Linux and servers in general just as a hobby and don't actually have an education in this field.

Improve this question
2
  • Does this help? Commented Aug 3, 2024 at 18:00
  • Yup, that did it. I actually now remember having tried this before, but I think I made a formatting error so it didn't work. Anyway, thanks for your reply. Commented Aug 4, 2024 at 0:22

1 Answer 1

Reset to default
1

The procedure described in the post linked in this comment worked. You first have to edit the connman config file under /etc/connman/main.conf and uncomment the NetworkInterfaceBlacklist configuration option. Then you just add whatever interfaces you don't want taking over your default route, which in my case were veth and vnet. It should then look something like this: NetworkInterfaceBlacklist = veth, vnet. Now you just go ahead and save it, and restart the connman service via systemctl restart connman for it to take effect.

I have tried this method before, but did not manage to fix the problem with it, as I accidentally added a Hyphen to the Interface blacklist entry (veth- instead of veth). Now, after trying it again, it worked flawlessly.

Improve this answer
2
  • Congratulations. ;) May I suggest that you a) add the outlined process to your self-answer and b) accept it? This should help pulling traffic to such questions here - it's really off-topic where I found it. Commented Aug 4, 2024 at 1:51
  • Just edited my answer, I hope it's alright this way now. I'll have to wait with marking it as the correct answer until tomorrow though, as the Site is preventing me from doing it now. Commented Aug 4, 2024 at 10:24

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.