Bringing up a container creates default routes on host which cause problems

When I create a new container, as soon as I initiate any network activity (eg an apt update), two new default routes appear on the host, disrupting networking. At present I am dealing with this by manually deleting them (which doesn’t seem to cause any problems for the container or Incus), but I would like to know how I can prevent this.

Steps to reproduce:

  1. create new container
    incus launch images:debian/12 test

  2. make an outbound connection inside the container

$ incus shell test
root@test:~# apt update
  1. compare ip route output on host
$ ip route
default via 192.168.1.1 dev enp1s0 
10.51.132.0/24 dev incusbr0 proto kernel scope link src 10.51.132.1 
169.254.0.0/16 dev vetha3ea216e proto kernel scope link src 169.254.161.152 
169.254.0.0/16 dev veth367c4bc7 proto kernel scope link src 169.254.168.53 
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.229 
192.168.1.1 dev enp1s0 scope li0.0.0.0 dev veth6284239d scope link

AFTER

0.0.0.0 dev veth6284239d scope link 
default dev veth6284239d scope link 
default via 192.168.1.1 dev enp1s0 
10.51.132.0/24 dev incusbr0 proto kernel scope link src 10.51.132.1 
169.254.0.0/16 dev vetha3ea216e proto kernel scope link src 169.254.161.152 
169.254.0.0/16 dev veth367c4bc7 proto kernel scope link src 169.254.168.53 
169.254.0.0/16 dev veth6284239d proto kernel scope link src 169.254.173.106 
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.229 
192.168.1.1 dev enp1s0 scope link

This is a minimal Incus install that followed the defaults with an Incus-managed bridge network:

$ incus profile show default
config: {}
description: Default Incus profile
devices:
  incusbr0:
    nictype: bridged
    parent: incusbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default

The new default routes disrupt networking because some applications try to use the container’s virtual interface instead of the enp1s0 interface.

What host OS are you running Incus on?

I’m definitely not seeing this behavior here and that feels extremely wrong considering that the veth device would be bridged which usually prevent any direction interaction with it.
This looks a lot like some kind of network configuration manager on the system being a bit over enthusiastic about new devices and trying to send traffic through them.

Thanks, that’s helping me figure out where to look.

I’m running Debian 12, with the ethernet card configured statically through /etc/interfaces

auto enp1s0
iface enp1s0 inet static 
        address 192.168.1.229/24
        gateway 192.168.1.1

The box was originally running LXDE on top so maybe something from that desktop environment is running that I’m not aware of? I’ll investigate and report back.

Thank you Stéphane, that was the clue I needed. The problem was the connman daemon which LXDE uses to manage networking. I have removed connman from the system and everything words as expected.