# Perte de connection internet depuis machine debian probleme ip route, lié à docker \[résolu\] **URL:** \ **Category:** Support Debian\ **Created:** [Novembre 10, 2025, 11:18 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742 "2025-11-10T23:18:45Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 10, 2025, 11:18 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/1 "2025-11-10T23:18:45Z")
Bonjour à tous, voici mon problème. j’ai une debian 12 (bookworm) récemment installée sur un PC avec docker pour faire tourner home assistant (le raspberry était un peu limite). Tout fonctionnait bien jusqu’à il y a qques jours, sans que je sache la modif qui a été apportée au système, mais cette machine n’accède plus à internet. le réseau local fonctionne parfaitement, j’y accède en SSH et accès aux fichiers en NFS. Mon accès internet via box SFR fonctionne parfaitement aussi pour toutes les autres machines. voilà où j’en suis de mes recherches et je bloque. Je suspecte un problème de doublon dans route que je n’arrive pas à supprimer. Alors voici les résultats de commandes que j’ai trouvé sur les forums parcourus depuis quelques heures maintenant. mon fichier interfaces (que j’ai tenté de modifier) : > #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 > > #auto eth0 > #The primary network interface > iface enp1s0 inet dhcp * * * ~# ip route > 0.0.0.0 dev veth8131e99 scope link > 0.0.0.0 dev vethc3de6e2 scope link > 0.0.0.0 dev vetha88ca7e scope link > default dev vetha88ca7e scope link > 169.254.0.0/16 dev vetha88ca7e proto kernel scope link src 169.254.69.58 > 169.254.0.0/16 dev vethc3de6e2 proto kernel scope link src 169.254.174.16 > 169.254.0.0/16 dev veth8131e99 proto kernel scope link src 169.254.23.65 > 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 > 192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.26 > 192.168.1.1 dev enp1s0 scope link ~# traceroute 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 pcdomo.local (169.254.69.58) 3060.475 ms !H 3060.391 ms !H 3060.349 ms !H ~# nmcli device status > DEVICE TYPE STATE CONNECTION > enp1s0 ethernet connecté Connexion filaire 1 > docker0 bridge connecté (en externe) docker0 > lo loopback connecté (en externe) lo > wlp2s0 wifi déconnecté – > p2p-dev-wlp2s0 wifi-p2p déconnecté – > veth8131e99 ethernet non-géré – > vetha88ca7e ethernet non-géré – > vethc3de6e2 ethernet non-géré – ~# nmcli connection show enp1s0 > Erreur : enp1s0 - profil de connexion introuvable. ~# nslookup [debian-fr.org](http://debian-fr.org) > Server: 192.168.1.1 > Address: 192.168.1.1#53 > Non-authoritative answer: > Name: [debian-fr.org](http://debian-fr.org) > Address: 82.65.201.202 ~# ip link > 1: lo: \ mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: enp1s0: \ mtu 1500 qdisc fq\_codel state UP mode DEFAULT group default qlen 1000 > link/ether 14:b3:1f:25:1a:08 brd ff:ff:ff:ff:ff:ff > 3: wlp2s0: \ mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000 > link/ether ce:39:64:c7:f7:cf brd ff:ff:ff:ff:ff:ff permaddr bc:a8:a6:a9:3c:88 > 4: docker0: \ mtu 1500 qdisc noqueue state UP mode DEFAULT group default > link/ether 42:88:c3:f6:3c:7c brd ff:ff:ff:ff:ff:ff > 5: vetha88ca7e@if2: \ mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default > link/ether 92:7e:cf:15:18:3a brd ff:ff:ff:ff:ff:ff link-netnsid 0 > 6: vethc3de6e2@if2: \ mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default > link/ether 26:30:e3:ac:56:3f brd ff:ff:ff:ff:ff:ff link-netnsid 1 > 7: veth8131e99@if2: \ mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default > link/ether d2:6b:b5:39:3e:87 brd ff:ff:ff:ff:ff:ff link-netnsid 2 Voilà donc où j’en suis, et de l’aide serait fortement appréciée. J’espère que les infos postées peuvent commencer à poser un diagnostic. Merci beaucoup. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 11, 2025, 11:22 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/2 "2025-11-11T11:22:17Z")
Bonjour, si tu as nmcli, c’est que utilises NetworkManager, donc le fichier /etc/netwotk/interfaces n’a pas à être utilisé, il doit être vide. Ton interface principale n’a pas d’adresse donc pas d’accès internet. A quoi correspondent les interfaces 5 à 7? ---
**Author:** ![anon95513332](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/aeb1de/32.png) [@anon95513332](https://www.debian-fr.org/u/anon95513332)\ **Post date:** [Novembre 11, 2025, 12:21 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/3 "2025-11-11T12:21:44Z")
Hello, Un message sur ce forum qui ne commence pas par « Bonjour » ou un équivalent, je ne réponds pas. Bonne journée, ---
**Author:** ![dindoun](https://www.debian-fr.org/user_avatar/www.debian-fr.org/dindoun/32/4281_2.png) [@dindoun](https://www.debian-fr.org/u/dindoun)\ **Post date:** [Novembre 11, 2025, 1:30 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/4 "2025-11-11T13:30:07Z")
> [@nico\_34](#): > > cette machine n’accède plus à internet. j’ai l’impression que oui : tu as de nombreuses réponses un problème avec ton dns? ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 11, 2025, 6:34 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/5 "2025-11-11T18:34:03Z")
Merci Zargos, tu m’a déjà donné quelques pistes qui vont limiter mon rayon d’investigation en me focusant sur network manager. Je vais voir si j’y arrive seul à partir de là. Les interfaces 5 à 7 : je me pose la même question. Aucune idée. Ma machine accède à mon raspberry sur mon réseau local (programmé comme des intégrations en YAML de mon home assistant sur docker), est ce que ça créerait des connections en plus? Je ne vois pas pourquoi? ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 11, 2025, 6:37 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/6 "2025-11-11T18:37:31Z")
Bonjour Necromago, désolé pour l’entrée en matière un peu brute, j’ai corrigé. J’étais pourtant content de mon post qui donnait un maximum de détail à analyser aux experts et ne se contentait pas de dire "bonjour, mon internet ne marche plus, comment faire? " Et c’est vrai que je me rend compte quand je rédige un email que je commence but en blanc par ce que j’ai à dire, et ensuite je reviens mettre les formules de politesses de début et de fin en fonction de l’interlocuteur à qui je m’adresse. Je serai plus vigilant à l’avenir. ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 11, 2025, 6:43 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/7 "2025-11-11T18:43:39Z")
bonjour dindoun, je ne comprend pas « oui » à quoi dans ta réponse. Si c’est accès à internet par cette machine, je confirme que c’est non, j’utilise un autre ordi pour me connecter. et pour le serveur DNS, si je comprend bien le fonctionnement, c’est ma box qui assure ce service, et cherche le lien entre les sites demandés et leur adresse IP? nslookup me donne bien une adresse, mais qui est fausse puisque ça m’amène à un site zehome de courses de voitures!? et non [debian-fr.org](http://debian-fr.org); alors là, je ne sais quoi en penser. Mais je crois que le problème est bien avant le DNS. je vais creuser la réponse de zargos sur l’interface principale à paramétrer avec nmcli. ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 11, 2025, 11:33 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/8 "2025-11-11T23:33:53Z")
Bonjour à tous et merci à ceux qui m’aident, j’ai donc effacé tout ce qu’il y avait dans le fichier interface pour que network manager fasse le job. Pour préciser le sujet, je peux accéder à mon home assistant (donc à cet ordi) depuis l’extérieur de la maison, car j’ai ouvert un port sur ma box. Donc l’ordi est bien relié à internet et j’arrive à l’interroger à distance sans problème. donc déjà il n’y a pas de problème de connexion physique. C’est comme si ma box lui bloquait les accès sortants à internet. Le fait d’avoir ouvert des ports entrants peut être lié à ce problème? avec nmcli j’ai créé la connection wifi, et ça fonctionne, je vois sur l’interface de ma box cet ordi apparaitre avec une autre adresse IP en WIFI. Ma box le voit donc deux fois, en filaire avec adresse IP 192.168.1.26 et en WIFI avec adresse IP 192.168.1.32. sur ma box, j’ai ces deux redirections de ports pour accès distant : Num | Nom Protocole | Type | Ports externes | IP de destination | Ports de destination 2 | HA\_PC | TCP |Port | 51510 | 192.168.1.26 |8123 3 | NodeRed | TCP | Port | 51511 | 192.168.1.26 | 1880 pour moi, cela n’a aucun rapport, mais bon je le précise. un test ping 8.8.8.8 me donne la même chose qu’hier : ~# ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. > From 169.254.69.58 icmp\_seq=1 Destination Host Unreachable > From 169.254.69.58 icmp\_seq=2 Destination Host Unreachable > From 169.254.69.58 icmp\_seq=3 Destination Host Unreachable > From 169.254.69.58 icmp\_seq=4 Destination Host Unreachable > From 169.254.69.58 icmp\_seq=5 Destination Host Unreachable > From 169.254.69.58 icmp\_seq=6 Destination Host Unreachable > ^C > — 8.8.8.8 ping statistics — > 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7162ms > pipe 4 Et donc mon nmcli connection show donne ça. Je ne comprend pas tout mais ça me semble normal. > connection.id: Connexion filaire 1 > connection.uuid: e410d8a6-6574-38d8-b94e-1a9f19960270 > connection.stable-id: – > connection.type: 802-3-ethernet > connection.interface-name: enp1s0 > connection.autoconnect: oui > connection.autoconnect-priority: -999 > connection.autoconnect-retries: -1 (default) > connection.multi-connect: 0 (default) > connection.auth-retries: -1 > connection.timestamp: 1762813044 > connection.read-only: non > connection.permissions: – > connection.zone: – > connection.master: – > connection.slave-type: – > connection.autoconnect-slaves: -1 (default) > connection.secondaries: – > connection.gateway-ping-timeout: 0 > connection.metered: inconnu > connection.lldp: default > connection.mdns: -1 (default) > connection.llmnr: -1 (default) > connection.dns-over-tls: -1 (default) > connection.mptcp-flags: 0x0 (default) > connection.wait-device-timeout: -1 > connection.wait-activation-delay: -1 > 802-3-ethernet.port: – > 802-3-ethernet.speed: 0 > 802-3-ethernet.duplex: – > 802-3-ethernet.auto-negotiate: non > 802-3-ethernet.mac-address: – > 802-3-ethernet.cloned-mac-address: – > 802-3-ethernet.generate-mac-address-mask:– > 802-3-ethernet.mac-address-blacklist: – > 802-3-ethernet.mtu: auto > 802-3-ethernet.s390-subchannels: – > 802-3-ethernet.s390-nettype: – > 802-3-ethernet.s390-options: – > 802-3-ethernet.wake-on-lan: default > 802-3-ethernet.wake-on-lan-password: – > 802-3-ethernet.accept-all-mac-addresses:-1 (default) > ipv4.method: auto > ipv4.dns: – > ipv4.dns-search: – > ipv4.dns-options: – > ipv4.dns-priority: 0 > ipv4.addresses: – > ipv4.gateway: – > ipv4.routes: – > ipv4.route-metric: -1 > ipv4.route-table: 0 (unspec) > ipv4.routing-rules: – > ipv4.replace-local-rule: -1 (default) > ipv4.ignore-auto-routes: non > ipv4.ignore-auto-dns: non > ipv4.dhcp-client-id: – > ipv4.dhcp-iaid: – > ipv4.dhcp-timeout: 0 (default) > ipv4.dhcp-send-hostname: oui > ipv4.dhcp-hostname: – > ipv4.dhcp-fqdn: – > ipv4.dhcp-hostname-flags: 0x0 (none) > ipv4.never-default: non > ipv4.may-fail: oui > ipv4.required-timeout: -1 (default) > ipv4.dad-timeout: -1 (default) > ipv4.dhcp-vendor-class-identifier: – > ipv4.link-local: 0 (default) > ipv4.dhcp-reject-servers: – > ipv4.auto-route-ext-gw: -1 (default) > ipv6.method: auto > ipv6.dns: – > ipv6.dns-search: – > ipv6.dns-options: – > ipv6.dns-priority: 0 > ipv6.addresses: – > ipv6.gateway: – > ipv6.routes: – > ipv6.route-metric: -1 > ipv6.route-table: 0 (unspec) > ipv6.routing-rules: – > ipv6.replace-local-rule: -1 (default) > ipv6.ignore-auto-routes: non > ipv6.ignore-auto-dns: non > ipv6.never-default: non > ipv6.may-fail: oui > ipv6.required-timeout: -1 (default) > ipv6.ip6-privacy: -1 (unknown) > ipv6.addr-gen-mode: default > ipv6.ra-timeout: 0 (default) > ipv6.mtu: auto > ipv6.dhcp-duid: – > ipv6.dhcp-iaid: – > ipv6.dhcp-timeout: 0 (default) > ipv6.dhcp-send-hostname: oui > ipv6.dhcp-hostname: – > ipv6.dhcp-hostname-flags: 0x0 (none) > ipv6.auto-route-ext-gw: -1 (default) > ipv6.token: – > proxy.method: none > proxy.browser-only: non > proxy.pac-url: – > proxy.pac-script: – > GENERAL.NAME: Connexion filaire 1 > GENERAL.UUID: e410d8a6-6574-38d8-b94e-1a9f19960270 > GENERAL.DEVICES: enp1s0 > GENERAL.IP-IFACE: enp1s0 > GENERAL.STATE: activé > GENERAL.DEFAULT: oui > GENERAL.DEFAULT6: non > GENERAL.SPEC-OBJECT: – > GENERAL.VPN: non > GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveC\> > GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Setting\> > GENERAL.ZONE: – > GENERAL.MASTER-PATH: – > IP4.ADDRESS[1]: 192.168.1.26/24 > IP4.GATEWAY: 192.168.1.1 > IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt \> > IP4.ROUTE[2]: dst = 192.168.1.1/32, nh = 0.0.0.0, mt \> > IP4.ROUTE[3]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt \> > IP4.ROUTE[4]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt =\> > IP4.DNS[1]: 192.168.1.1 > DHCP4.OPTION[1]: broadcast\_address = 192.168.1.255 > DHCP4.OPTION[2]: dhcp\_client\_identifier = 01:14:b3:1f:25\> > DHCP4.OPTION[3]: dhcp\_lease\_time = 86400 > DHCP4.OPTION[4]: dhcp\_server\_identifier = 192.168.1.1 > DHCP4.OPTION[5]: domain\_name\_servers = 192.168.1.1 > DHCP4.OPTION[6]: expiry = 1762982764 > DHCP4.OPTION[7]: host\_name = pcdomo > DHCP4.OPTION[8]: ip\_address = 192.168.1.26 > DHCP4.OPTION[9]: next\_server = 192.168.1.1 > DHCP4.OPTION[10]: ntp\_servers = 192.168.1.1 > DHCP4.OPTION[11]: requested\_broadcast\_address = 1 > DHCP4.OPTION[12]: requested\_domain\_name = 1 > DHCP4.OPTION[13]: requested\_domain\_name\_servers = 1 > DHCP4.OPTION[14]: requested\_domain\_search = 1 > lines 116-138 > GENERAL.ZONE: – > GENERAL.MASTER-PATH: – > IP4.ADDRESS[1]: 192.168.1.26/24 > IP4.GATEWAY: 192.168.1.1 > IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt =\> > IP4.ROUTE[2]: dst = 192.168.1.1/32, nh = 0.0.0.0, mt =\> > IP4.ROUTE[3]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt =\> > IP4.ROUTE[4]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = \> > IP4.DNS[1]: 192.168.1.1 > DHCP4.OPTION[1]: broadcast\_address = 192.168.1.255 > DHCP4.OPTION[2]: dhcp\_client\_identifier = 01:14:b3:1f:25:\> > DHCP4.OPTION[3]: dhcp\_lease\_time = 86400 > DHCP4.OPTION[4]: dhcp\_server\_identifier = 192.168.1.1 > DHCP4.OPTION[5]: domain\_name\_servers = 192.168.1.1 > DHCP4.OPTION[6]: expiry = 1762982764 > DHCP4.OPTION[7]: host\_name = pcdomo > DHCP4.OPTION[8]: ip\_address = 192.168.1.26 > DHCP4.OPTION[9]: next\_server = 192.168.1.1 > DHCP4.OPTION[10]: ntp\_servers = 192.168.1.1 > DHCP4.OPTION[11]: requested\_broadcast\_address = 1 > DHCP4.OPTION[12]: requested\_domain\_name = 1 > DHCP4.OPTION[13]: requested\_domain\_name\_servers = 1 > DHCP4.OPTION[14]: requested\_domain\_search = 1 > DHCP4.OPTION[15]: requested\_host\_name = 1 > DHCP4.OPTION[16]: requested\_interface\_mtu = 1 > DHCP4.OPTION[17]: requested\_ms\_classless\_static\_routes = 1 > DHCP4.OPTION[18]: requested\_nis\_domain = 1 > DHCP4.OPTION[19]: requested\_nis\_servers = 1 > DHCP4.OPTION[20]: requested\_ntp\_servers = 1 > DHCP4.OPTION[21]: requested\_rfc3442\_classless\_static\_routes = 1 > DHCP4.OPTION[22]: requested\_root\_path = 1 > DHCP4.OPTION[23]: requested\_routers = 1 > DHCP4.OPTION[24]: requested\_static\_routes = 1 > DHCP4.OPTION[25]: requested\_subnet\_mask = 1 > DHCP4.OPTION[26]: requested\_time\_offset = 1 > DHCP4.OPTION[27]: requested\_wpad = 1 > DHCP4.OPTION[28]: routers = 192.168.1.1 > DHCP4.OPTION[29]: subnet\_mask = 255.255.255.0 > IP6.ADDRESS[1]: fe80::fc71:cd73:96e9:3292/64 > IP6.GATEWAY: – ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 12, 2025, 10:26 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/9 "2025-11-12T10:26:27Z")
Tes routes sont anormales: > [@nico\_34](#): > > IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt =\> > IP4.ROUTE[2]: dst = 192.168.1.1/32, nh = 0.0.0.0, mt =\> > IP4.ROUTE[3]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt =\> Tu as deux fois la même et celle en /32 n’a rien à faire là. Comment as-tu fait pour configurer ton réseau sur ton PC? ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 12, 2025, 7:01 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/10 "2025-11-12T19:01:39Z")
Ok merci, j’aurais été incapable de voir ça. Je n’ai jamai configuré mon réseau. J’ai installé Debian et il a tout configuré automatiquement, et ça marchait très bien. Je n’ai jamais tenté de modifier quoique ce soit sur ce PC à ce sujet, donc la modif a du se faire par une autre manip de manière détournée, que j’ignore. La seule chose que j’ai faite, c’est d’ouvrir mes deux ports pour accès distant. Après, il y a eu pas mal de coupures de courant pour travaux, mais je ne vois vraiment pas le rapport. Bref, comment repartir d’une install clean? je supprime la connection et je la recrée? avec nmcli? la meme commande aujourd’hui me donne ça, sans rien avoir changé de particulier mais ça ne marche toujours pas : IP4.ADDRESS[1]: 192.168.1.26/24 IP4.GATEWAY: 192.168.1.1 IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100 IP4.DNS[1]: 192.168.1.1 et je précise qu’en tapant les mêmes commandes sur mon raspberry, j’ai les mêmes infos, avec ROUTE[1] et ROUTE[2] ainsi que tout le reste, mais mon raspi accède à internet, et toujours pas ce PC. Grrrrrr!! Donc ça doit être autre chose. quand aux veth, ce sont des connection virtuelles, reliées à docker (elles donnent accès à internet aux applis docker si je comprend bien); [veth(4) - Linux manual page](https://www.man7.org/linux/man-pages/man4/veth.4.html) ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 12, 2025, 11:12 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/11 "2025-11-12T23:12:20Z")
alors après encore des heures passées, il semble que le problème soit bien diagnostiqué par traceroute, le premier saut devrait être sur la gateway (c’est ce que j’ai sur le raspi) alors que je retombe en local sur mon PC, avec une adresse 169.254.29.58 qui apparait sur un des virtual vetha88ca7e la question est donc comment réparer ça? c’est dans docker le problème? Et pourquoi ça marchait avant? la commande dig me donne ça : ça semble indiquer que le serveur DNS est bien le bon et je ping sans problème sur 192.168.1.1 > ``` > ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59006 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 > (...) > ;; Query time: 32 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP) > ;; WHEN: Thu Nov 13 00:25:30 CET 2025 > ;; MSG SIZE rcvd: 823 > > ``` ---
**Author:** ![nico\_34](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/f19dbf/32.png) [@nico\_34](https://www.debian-fr.org/u/nico_34)\ **Post date:** [Novembre 12, 2025, 11:47 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/12 "2025-11-12T23:47:55Z")
peut être une réponse ici : > > > \### Description > > After running Docker for an undetermined period, external conne…ctivity (outside the intranet) dies for both containers & the host. This is established by trying \`ping 8.8.8.8\` to eliminate DNS as an issue. The ping will timeout, although ping to internal networks (IP only, not hostname) will be fine. > > I only started seeing this issue after I upgraded a running Debian Bullseye system to Debian Bookworm in place. This is on a Raspberry Pi 4. > > After a bunch of trial and error, I saw that Docker adds a default route to my host system, such as: > \> default dev veth0f1ec05 scope link > > It's worth noting that whenever that default route is added, there is also a standard bridge route present. In this case it would be: > \> 0.0.0.0 dev veth0f1ec05 scope link > > I tried narrowing down that veth to a particular container, but the container seems to be random. I say this as I will shut down the container, and then Docker will recreate the default network route using another container. From reading the network daemon readme, that behavior seems to correlate with how Docker chooses gateways, so this part \_could\_ be standard behavior, but I can't be certain. > > After doing some digging, I saw some issues here with similar behavior related to \[iptables\](https://github.com/moby/moby/issues/49537) & \[firewall\](https://github.com/moby/moby/issues/46147), so I included my iptables below - both when the \`default dev veth\` is present and when it is not. > > Please note that I also tried to block veth in connman per \[this comment\](https://github.com/moby/moby/issues/46147#issuecomment-2677874955), but that just prevented any veth routes from being added, causing Docker containers to have no connectivity. The host's network worked though! > > \### Reproduce > > This occurs whenever docker is run, so I don't have any clear repro steps to \_create\_ the bug, but I have steps to \_remove\_ the bug (until Docker automatically overrides this change). > > The only thing I can think that may be unique to my setup is that I recently upgraded from Debian Bullseye to Bookworm. When this first issue occurred, I uninstalled docker then reinstalled docker. The packages used had changed since when I first installed docker (wasn't called community?), so I do have concern there are old network rules lying around somewhere (although I did delete the docker network directory as well before reinstallation. > > > The temp fix is to run: > \`sudo ip route show default | awk '{print $3}' | grep veth | xargs -I {} sudo ip route del default dev {}\` > > The breakdown of this command being: > > \- \`sudo ip route show default\`: Get the list of default routes > \- \`awk '{print $3}'\`: Print the gateways listed for the default routes > \- \`grep veth\`: Find any virtual (docker) interfaces > \- \`sudo ip route del default dev\`: Remove them > > In this state, all network connectivity seems to work for both containers & host. > > \### Expected behavior > > Docker should be able to manage container networks without affecting host network. > > My guess is this is some unexpected interaction between different network managers and docker. > > \### docker version > > \`\`\`bash > Client: Docker Engine - Community > Version: 28.0.1 > API version: 1.48 > Go version: go1.23.6 > Git commit: 068a01e > Built: Wed Feb 26 10:40:57 2025 > OS/Arch: linux/arm64 > Context: default > > Server: Docker Engine - Community > Engine: > Version: 28.0.1 > API version: 1.48 (minimum version 1.24) > Go version: go1.23.6 > Git commit: bbd0a17 > Built: Wed Feb 26 10:40:57 2025 > OS/Arch: linux/arm64 > Experimental: false > containerd: > Version: 1.7.25 > GitCommit: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb > runc: > Version: 1.2.4 > GitCommit: v1.2.4-0-g6c52b3f > docker-init: > Version: 0.19.0 > GitCommit: de40ad0 > \`\`\` > > \### docker info > > \`\`\`bash > Client: Docker Engine - Community > Version: 28.0.1 > Context: default > Debug Mode: false > Plugins: > buildx: Docker Buildx (Docker Inc.) > Version: v0.21.1 > Path: /usr/libexec/docker/cli-plugins/docker-buildx > compose: Docker Compose (Docker Inc.) > Version: v2.33.1 > Path: /usr/libexec/docker/cli-plugins/docker-compose > > Server: > Containers: 13 > Running: 12 > Paused: 0 > Stopped: 1 > Images: 13 > Server Version: 28.0.1 > Storage Driver: overlay2 > Backing Filesystem: extfs > Supports d\_type: true > Using metacopy: false > Native Overlay Diff: true > userxattr: false > Logging Driver: json-file > Cgroup Driver: systemd > Cgroup Version: 2 > Plugins: > Volume: local > Network: bridge host ipvlan macvlan null overlay > Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog > Swarm: inactive > Runtimes: io.containerd.runc.v2 runc > Default Runtime: runc > Init Binary: docker-init > containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb > runc version: v1.2.4-0-g6c52b3f > init version: de40ad0 > Security Options: > seccomp > Profile: builtin > cgroupns > Kernel Version: 6.1.21-v8+ > Operating System: Debian GNU/Linux 12 (bookworm) > OSType: linux > Architecture: aarch64 > CPUs: 4 > Total Memory: 3.705GiB > Name: \[Redacted\] > ID: 157015b4-\[Redacted\] > Docker Root Dir: /var/lib/docker > Debug Mode: false > Experimental: false > Insecure Registries: > ::1/128 > 127.0.0.0/8 > Live Restore Enabled: false > > WARNING: No memory limit support > WARNING: No swap limit support > \`\`\` > > \### Additional Info > > \*\*Working state\*\* > \_Note: While I do have tailscale installed, it is down in order to remove that as a variable. I also tried uninstalling tailscale and the issue still remained.\_ > \> ~ $ ip route show > \> 0.0.0.0 dev veth0f1ec05 scope link > \> 0.0.0.0 dev veth3811101 scope link > \> 0.0.0.0 dev veth3dd9602 scope link > \> 0.0.0.0 dev veth916be7e scope link > \> 0.0.0.0 dev veth90c7af9 scope link > \> 0.0.0.0 dev veth94fde12 scope link > \> 0.0.0.0 dev vethcc32945 scope link > \> 0.0.0.0 dev vethf32f5ab scope link > \> 0.0.0.0 dev vethb75e7d8 scope link > \> 0.0.0.0 dev veth54445a2 scope link > \> 0.0.0.0 dev vethf714226 scope link > \> 0.0.0.0 dev veth9501d83 scope link > \> default via 192.168.1.1 dev eth0 > \> default via 192.168.1.1 dev eth0 proto static metric 100 onlink > \> 169.254.0.0/16 dev veth9501d83 proto kernel scope link src 169.254.3.81 > \> 169.254.0.0/16 dev vethf714226 proto kernel scope link src 169.254.236.175 > \> 169.254.0.0/16 dev veth54445a2 proto kernel scope link src 169.254.118.35 > \> 169.254.0.0/16 dev vethb75e7d8 proto kernel scope link src 169.254.125.33 > \> 169.254.0.0/16 dev vethf32f5ab proto kernel scope link src 169.254.40.186 > \> 169.254.0.0/16 dev vethcc32945 proto kernel scope link src 169.254.167.12 > \> 169.254.0.0/16 dev veth94fde12 proto kernel scope link src 169.254.27.107 > \> 169.254.0.0/16 dev veth90c7af9 proto kernel scope link src 169.254.151.192 > \> 169.254.0.0/16 dev veth916be7e proto kernel scope link src 169.254.106.252 > \> 169.254.0.0/16 dev veth3dd9602 proto kernel scope link src 169.254.50.36 > \> 169.254.0.0/16 dev veth3811101 proto kernel scope link src 169.254.239.49 > \> 169.254.0.0/16 dev veth0f1ec05 proto kernel scope link src 169.254.62.17 > \> 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 > \> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.55 > \> 192.168.1.1 dev eth0 scope link > > \> ~ $ sudo iptables -nvL > \> # Warning: iptables-legacy tables present, use iptables-legacy to see them > \> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> 2867K 4291M ts-input 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> 47323 34M DOCKER-USER 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 47323 34M DOCKER-FORWARD 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 55 6564 ts-forward 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> > \> Chain DOCKER (2 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.12 tcp dpt:9117 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.9 tcp dpt:8080 > \> 54 3456 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.8 tcp dpt:9443 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.8 tcp dpt:8000 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.7 tcp dpt:5076 > \> 29 1856 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.6 tcp dpt:8989 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.5 tcp dpt:9090 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.5 tcp dpt:8080 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.4 tcp dpt:6767 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:7878 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:8123 > \> 0 0 DROP 0 -- !docker0 docker0 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DROP 0 -- !br-2354dca551ef br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-BRIDGE (1 references) > \> pkts bytes target prot opt in out source destination > \> 83 5312 DOCKER 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DOCKER 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-CT (1 references) > \> pkts bytes target prot opt in out source destination > \> 8183 4097K ACCEPT 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED > \> 5424 6156K ACCEPT 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED > \> > \> Chain DOCKER-FORWARD (1 references) > \> pkts bytes target prot opt in out source destination > \> 47323 34M DOCKER-CT 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 25823 13M DOCKER-ISOLATION-STAGE-1 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 25823 13M DOCKER-BRIDGE 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 20388 13M ACCEPT 0 -- docker0 \* 0.0.0.0/0 0.0.0.0/0 > \> 2102 380K ACCEPT 0 -- br-2354dca551ef \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-ISOLATION-STAGE-1 (1 references) > \> pkts bytes target prot opt in out source destination > \> 20388 13M DOCKER-ISOLATION-STAGE-2 0 -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 > \> 2102 380K DOCKER-ISOLATION-STAGE-2 0 -- br-2354dca551ef !br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-ISOLATION-STAGE-2 (2 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 DROP 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DROP 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-USER (1 references) > \> pkts bytes target prot opt in out source destination > \> 176K 141M RETURN 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain ts-forward (1 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 MARK 0 -- tailscale0 \* 0.0.0.0/0 0.0.0.0/0 MARK xset 0x40000/0xff0000 > \> 0 0 ACCEPT 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 mark match 0x40000/0xff0000 > \> 0 0 DROP 0 -- \* tailscale0 100.64.0.0/10 0.0.0.0/0 > \> 0 0 ACCEPT 0 -- \* tailscale0 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain ts-input (1 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 ACCEPT 0 -- lo \* 100.89.127.64 0.0.0.0/0 > \> 0 0 RETURN 0 -- !tailscale0 \* 100.115.92.0/23 0.0.0.0/0 > \> 0 0 DROP 0 -- !tailscale0 \* 100.64.0.0/10 0.0.0.0/0 > \> 1 51 ACCEPT 0 -- tailscale0 \* 0.0.0.0/0 0.0.0.0/0 > \> 1311 78660 ACCEPT 17 -- \* \* 0.0.0.0/0 0.0.0.0/0 udp dpt:41641 > > \> $ sudo iptables-legacy -nvL > \> Chain INPUT (policy ACCEPT 3648K packets, 5245M bytes) > \> pkts bytes target prot opt in out source destination > \> > \> Chain FORWARD (policy ACCEPT 202K packets, 154M bytes) > \> pkts bytes target prot opt in out source destination > \> > \> Chain OUTPUT (policy ACCEPT 2404K packets, 7579M bytes) > \> pkts bytes target prot opt in out source destination > > > \*\*NON-Working state\*\* (Key difference in bold) > \> $ ip route show > \> 0.0.0.0 dev veth0f1ec05 scope link > \> 0.0.0.0 dev veth3811101 scope link > \> 0.0.0.0 dev veth3dd9602 scope link > \> 0.0.0.0 dev veth916be7e scope link > \> 0.0.0.0 dev veth90c7af9 scope link > \> 0.0.0.0 dev veth94fde12 scope link > \> 0.0.0.0 dev vethcc32945 scope link > \> 0.0.0.0 dev vethf32f5ab scope link > \> 0.0.0.0 dev vethb75e7d8 scope link > \> 0.0.0.0 dev veth54445a2 scope link > \> 0.0.0.0 dev vethf714226 scope link > \> 0.0.0.0 dev veth9501d83 scope link > \> \*\*default dev veth0f1ec05 scope link\*\* > \> default via 192.168.1.1 dev eth0 > \> default via 192.168.1.1 dev eth0 proto static metric 100 onlink > \> 169.254.0.0/16 dev veth9501d83 proto kernel scope link src 169.254.3.81 > \> 169.254.0.0/16 dev vethf714226 proto kernel scope link src 169.254.236.175 > \> 169.254.0.0/16 dev veth54445a2 proto kernel scope link src 169.254.118.35 > \> 169.254.0.0/16 dev vethb75e7d8 proto kernel scope link src 169.254.125.33 > \> 169.254.0.0/16 dev vethf32f5ab proto kernel scope link src 169.254.40.186 > \> 169.254.0.0/16 dev vethcc32945 proto kernel scope link src 169.254.167.12 > \> 169.254.0.0/16 dev veth94fde12 proto kernel scope link src 169.254.27.107 > \> 169.254.0.0/16 dev veth90c7af9 proto kernel scope link src 169.254.151.192 > \> 169.254.0.0/16 dev veth916be7e proto kernel scope link src 169.254.106.252 > \> 169.254.0.0/16 dev veth3dd9602 proto kernel scope link src 169.254.50.36 > \> 169.254.0.0/16 dev veth3811101 proto kernel scope link src 169.254.239.49 > \> 169.254.0.0/16 dev veth0f1ec05 proto kernel scope link src 169.254.62.17 > \> 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 > \> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.55 > \> 192.168.1.1 dev eth0 scope link > > \> $ sudo iptables -nvL > \> # Warning: iptables-legacy tables present, use iptables-legacy to see them > \> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> 2806K 4213M ts-input 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> 45698 33M DOCKER-USER 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 45698 33M DOCKER-FORWARD 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 55 6564 ts-forward 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) > \> pkts bytes target prot opt in out source destination > \> > \> Chain DOCKER (2 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.12 tcp dpt:9117 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.9 tcp dpt:8080 > \> 54 3456 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.8 tcp dpt:9443 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.8 tcp dpt:8000 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.7 tcp dpt:5076 > \> 29 1856 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.6 tcp dpt:8989 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.5 tcp dpt:9090 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.5 tcp dpt:8080 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.4 tcp dpt:6767 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:7878 > \> 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:8123 > \> 0 0 DROP 0 -- !docker0 docker0 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DROP 0 -- !br-2354dca551ef br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-BRIDGE (1 references) > \> pkts bytes target prot opt in out source destination > \> 83 5312 DOCKER 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DOCKER 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-CT (1 references) > \> pkts bytes target prot opt in out source destination > \> 7831 3909K ACCEPT 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED > \> 5317 6100K ACCEPT 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED > \> > \> Chain DOCKER-FORWARD (1 references) > \> pkts bytes target prot opt in out source destination > \> 45698 33M DOCKER-CT 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 24657 13M DOCKER-ISOLATION-STAGE-1 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 24657 13M DOCKER-BRIDGE 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> 19388 12M ACCEPT 0 -- docker0 \* 0.0.0.0/0 0.0.0.0/0 > \> 1936 346K ACCEPT 0 -- br-2354dca551ef \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-ISOLATION-STAGE-1 (1 references) > \> pkts bytes target prot opt in out source destination > \> 19388 12M DOCKER-ISOLATION-STAGE-2 0 -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 > \> 1936 346K DOCKER-ISOLATION-STAGE-2 0 -- br-2354dca551ef !br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-ISOLATION-STAGE-2 (2 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 DROP 0 -- \* br-2354dca551ef 0.0.0.0/0 0.0.0.0/0 > \> 0 0 DROP 0 -- \* docker0 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain DOCKER-USER (1 references) > \> pkts bytes target prot opt in out source destination > \> 174K 141M RETURN 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain ts-forward (1 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 MARK 0 -- tailscale0 \* 0.0.0.0/0 0.0.0.0/0 MARK xset 0x40000/0xff0000 > \> 0 0 ACCEPT 0 -- \* \* 0.0.0.0/0 0.0.0.0/0 mark match 0x40000/0xff0000 > \> 0 0 DROP 0 -- \* tailscale0 100.64.0.0/10 0.0.0.0/0 > \> 0 0 ACCEPT 0 -- \* tailscale0 0.0.0.0/0 0.0.0.0/0 > \> > \> Chain ts-input (1 references) > \> pkts bytes target prot opt in out source destination > \> 0 0 ACCEPT 0 -- lo \* 100.89.127.64 0.0.0.0/0 > \> 0 0 RETURN 0 -- !tailscale0 \* 100.115.92.0/23 0.0.0.0/0 > \> 0 0 DROP 0 -- !tailscale0 \* 100.64.0.0/10 0.0.0.0/0 > \> 1 51 ACCEPT 0 -- tailscale0 \* 0.0.0.0/0 0.0.0.0/0 > \> 1283 76980 ACCEPT 17 -- \* \* 0.0.0.0/0 0.0.0.0/0 udp dpt:41641 > > > > For completeness: > > \> sudo docker network ls > \> NETWORK ID NAME DRIVER SCOPE > \> c65d07cc17e5 bridge bridge local > \> 382d9aaccf88 host host local > \> 96f4ea037f99 none null local > > /etc/docker/daemon.json is empty Indeed editing `/etc/connman/main.conf` , uncommenting `# NetworkInterfaceBlacklist = vmnet,vboxnet,virbr,ifb,ve-,vb-` and adding `veth` to the list fixed the issue for me: ```auto # grep -i blacklist /etc/connman/main.conf # List of blacklisted network interfaces separated by ",". NetworkInterfaceBlacklist = vmnet,vboxnet,virbr,ifb,ve-,vb-,veth ``` Important note. After editing the config, I had to restart both connman and docker service, on that specific order. Restarting connman alone will restore connectivity on the host but not for running containers (and stopped/new containers will fail to start/run). ```auto # service connman restart # service docker restart ``` Trivial note: It seems Debian 12 does not come with connman as default. It’s Debian 12 desktop with LXDE that does. **Alleluya, c’était la solution, problème résolu** ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 13, 2025, 11:19 UTC](https://www.debian-fr.org/t/perte-de-connection-internet-depuis-machine-debian-probleme-ip-route-lie-a-docker-resolu/91742/13 "2025-11-13T11:19:17Z")
> [@nico\_34](#): > > IP4.ADDRESS[1]: 192.168.1.26/24 > IP4.GATEWAY: 192.168.1.1 > IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100 > IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100 > IP4.DNS[1]: 192.168.1.1 c’est nettement mieux 🙂