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:
-
create new container
incus launch images:debian/12 test
-
make an outbound connection inside the container
$ incus shell test
root@test:~# apt update
- 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.