Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

cause de blocage des messages icmp redirect sur un routeur linux ?

8 réponses
Avatar
Eric Belhomme
Bonjour,

sur un réseau, j'ai 2 routeurs :

- un routeur A (passerelle par défaut) est la porte de sortie vers
internet, sous Linux (Debian Sarge)

- un routeur B (faisant office de point d'accès WiFi)

J'ai configuré sur A une route vers B comme ceci :
# ip route add masque_B via B

J'espérais ainsi que mes pings depuis le LAN vers les machines WiFi
transiteraient vers A, que A emetterait un message icmp redirect, afin
que les tables de routages des stations de travail soient mises à jour
dynamiquement.

Hélas, le routeur A n'émet aucun message icmp_redirect ! a ma
connaissance, les critères qui définissent si Linux doit émettre des
icmp_redirect sont :
- Linux est configuré en mode routeur (c'est le cas)
- icmp_redirect est activé pour l'interface concernée :
# cat /proc/sys/net/ipv4/conf/eth0/*redirects
1
1
1

Il me semble pourtant que dans cette configuration, le message
icmp_redirect devrait être émis, il doit donc être bloqué quelque part,
mais où ???

--
Rico

8 réponses

Avatar
SiO
Eric Belhomme wrote:
Bonjour,

sur un réseau, j'ai 2 routeurs :

- un routeur A (passerelle par défaut) est la porte de sortie vers
internet, sous Linux (Debian Sarge)

- un routeur B (faisant office de point d'accès WiFi)

J'ai configuré sur A une route vers B comme ceci :
# ip route add masque_B via B

J'espérais ainsi que mes pings depuis le LAN vers les machines WiFi
transiteraient vers A, que A emetterait un message icmp redirect, afin
que les tables de routages des stations de travail soient mises à jour
dynamiquement.

Hélas, le routeur A n'émet aucun message icmp_redirect ! a ma
connaissance, les critères qui définissent si Linux doit émettre des
icmp_redirect sont :
- Linux est configuré en mode routeur (c'est le cas)
- icmp_redirect est activé pour l'interface concernée :
# cat /proc/sys/net/ipv4/conf/eth0/*redirects
1
1
1

Il me semble pourtant que dans cette configuration, le message
icmp_redirect devrait être émis, il doit donc être bloqué quelque part,
mais où ???



Salut.

Il manque beaucoup de détails pour avoir une idée claire du montage,
mais je vais essayer d'extrapoler quelques idées qui pouraient t'aider.

Si tu peux nous donner les infos suivantes:

- Ton router linux (A), il a combien d'interfaces réseau??
- À qui sont elles dédiées (eth0=Lan, eth1=modem internet, eth2=routerB)
- Quel est l'adressage IP de chacune de ces cartes (ip, mask, gateway) ?
- Comment as tu branché router A et B ensemble (ports utilisé...)?
- Quel est le modèle de ce router B ?

Généralement, si ton router B ne sert que de point d'access WI-FI tu
n'aurais même pas besoin de routage IP. La communication WI-FI, tout
comme ETHERNET sont des protocols de niveau 2. Tu devrais utiliser une
fonction de PONT sur ton router A pour joindre le router B au niveau
liaison (2). L'adressage IP du router B est nécessaire seulement pour
la gestion de ton router B (interface WEB) mais celui-ci peut faire
parti du même subnet ip que ton router A, donc pas de routage impliqué.
Fais attention au doublons d'ip, spécialement si tu as un serveur DHCP
qui roule sur un ou lautre des routers et que tu utilise du IP statique
sur tes machines.

Et il y a un peu de contradiction dans ce que tu dis. Tu dis que tu as
ajouté une route manuellement (statique), mais ensuite tu te surprend de
ne pas avoir de routes via un protocol de routage Dynamique. C'est
possible de router des routes statiques, mais je crois que ça commence à
compliquer les choses pour rien pour toi. Fais bien attention. Si tu
veux absolument avoir les 2 routers dans des plages IP différentes, et
que tu n'as pas de protocol de routage dynamique, et que tu ajoute des
routes statiques, n'oublie pas de les mettre dans les deux sens!! Ton
fameux paquet ICMP peut être qu'il se rend, mais qu'il ne revient pas,
simplement car de B vers A il n'y a aucune route. Mais si j'étais toi
j'oublirais cette option. Oublie le routage, cest n'est pas nécessaire.

DONC EN RÉSUMÉ, pas besoin de routage pour faire ce que tu veux faire.
Ton router B ne sert que d'ACCESS POINT simplement. Et en bout de ligne,
autant les PC sur le lan cablé sur A que les PC wi-fi sur B auront des
addresses IP dans le même sous réseau et possiblement du même serveur
DHCP (soit buit-in dans le router B ou dans LINUX/dhcpd mais attention
de ne pas avoir les 2 en meme temps!!) et suite a ceci tu pourras pigner
sans probleme tout ce beau monde.

Bonne chance.
SVP tiens nous au courant des développements.
Et N'hésite pas a poster un petit diagrame de ton montage!

PS: Sur linux, je te suggère SHOREWALL pour faire un tel travail
(firewall, pontage, routage, nat, etc, etc etc. Tres puissant.)

Avatar
Eric Belhomme
SiO wrote in
news:C9bwh.85509$:

- Ton router linux (A), il a combien d'interfaces réseau??
- À qui sont elles dédiées (eth0=Lan, eth1=modem internet,
eth2=routerB) - Quel est l'adressage IP de chacune de ces cartes (ip,
mask, gateway) ? - Comment as tu branché router A et B ensemble (ports
utilisé...)? - Quel est le modèle de ce router B ?

A possede 3 interfaces, eth0 est dédiée au LAN (192.168.1.0/24), sont ip

est 192.168.1.254.
B est connecté au LAN, son IP est 192.168.1.100. son interface wifi
(eth1) est sur le réseau 192.168.2.0/24 et sont IP est 192.168.2.254

Généralement, si ton router B ne sert que de point d'access WI-FI tu
n'aurais même pas besoin de routage IP. La communication WI-FI, tout
comme ETHERNET sont des protocols de niveau 2. Tu devrais utiliser
une fonction de PONT sur ton router A pour joindre le router B au
niveau liaison (2). L'adressage IP du router B est nécessaire
seulement pour la gestion de ton router B (interface WEB) mais
celui-ci peut faire parti du même subnet ip que ton router A, donc pas
de routage impliqué. Fais attention au doublons d'ip, spécialement si
tu as un serveur DHCP qui roule sur un ou lautre des routers et que tu
utilise du IP statique sur tes machines.

dans mon cas si, car je souhaite séparer les réseaux IP, donc routage


Et il y a un peu de contradiction dans ce que tu dis. Tu dis que tu
as ajouté une route manuellement (statique), mais ensuite tu te
surprend de ne pas avoir de routes via un protocol de routage
Dynamique. C'est possible de router des routes statiques, mais je
crois que ça commence à compliquer les choses pour rien pour toi. Fais
bien attention. Si tu veux absolument avoir les 2 routers dans des
plages IP différentes, et que tu n'as pas de protocol de routage
dynamique, et que tu ajoute des routes statiques, n'oublie pas de les
mettre dans les deux sens!!


Vu la complexité du réseau, un protocole de routage est superflux,
quelques routes rajoutées à bon escient sur les routeurs devraient
fonctionner tout aussi bien. En l'occurence, j'ai rajouté sur le routeur
A (passerelle par défaut) une route permettant aux hosts du LAN
d'atteindre le réseau IP du wifi. Les hosts wifi, eux, savent joindre
directement le LAN, puisque le routeur wifi a ajouté "naturellement" à sa
table de routage les bonnes routes pour aller de A vers B !

Ton fameux paquet ICMP peut être qu'il se
rend, mais qu'il ne revient pas, simplement car de B vers A il n'y a
aucune route. Mais si j'étais toi j'oublirais cette option. Oublie le
routage, cest n'est pas nécessaire.


non, un coup de tcpdump m'a montré qu'il n'est même pas émis par le
routeur

DONC EN RÉSUMÉ, pas besoin de routage pour faire ce que tu veux faire.
Ton router B ne sert que d'ACCESS POINT simplement. Et en bout de
ligne, autant les PC sur le lan cablé sur A que les PC wi-fi sur B
auront des addresses IP dans le même sous réseau et possiblement du
même serveur DHCP (soit buit-in dans le router B ou dans LINUX/dhcpd
mais attention de ne pas avoir les 2 en meme temps!!) et suite a ceci
tu pourras pigner sans probleme tout ce beau monde.

non ! B n'est pas un AP, c'est un routeur, dont une de ses interfaces est

wifi (en fait, B est aussi un hosts linux, avec une carte Prism54)

Bonne chance.
SVP tiens nous au courant des développements.
Et N'hésite pas a poster un petit diagrame de ton montage!

oula, en ASCII art, ca va etre coton !


PS: Sur linux, je te suggère SHOREWALL pour faire un tel travail
(firewall, pontage, routage, nat, etc, etc etc. Tres puissant.)

et moi je te suggères Debian :)


--
Rico

Avatar
SiO
Eric Belhomme wrote:
SiO wrote in
news:C9bwh.85509$:

- Ton router linux (A), il a combien d'interfaces réseau??
- À qui sont elles dédiées (eth0=Lan, eth1=modem internet,
eth2=routerB) - Quel est l'adressage IP de chacune de ces cartes (ip,
mask, gateway) ? - Comment as tu branché router A et B ensemble (ports
utilisé...)? - Quel est le modèle de ce router B ?

A possede 3 interfaces, eth0 est dédiée au LAN (192.168.1.0/24), sont ip

est 192.168.1.254.
B est connecté au LAN, son IP est 192.168.1.100. son interface wifi
(eth1) est sur le réseau 192.168.2.0/24 et sont IP est 192.168.2.254

Généralement, si ton router B ne sert que de point d'access WI-FI tu
n'aurais même pas besoin de routage IP. La communication WI-FI, tout
comme ETHERNET sont des protocols de niveau 2. Tu devrais utiliser
une fonction de PONT sur ton router A pour joindre le router B au
niveau liaison (2). L'adressage IP du router B est nécessaire
seulement pour la gestion de ton router B (interface WEB) mais
celui-ci peut faire parti du même subnet ip que ton router A, donc pas
de routage impliqué. Fais attention au doublons d'ip, spécialement si
tu as un serveur DHCP qui roule sur un ou lautre des routers et que tu
utilise du IP statique sur tes machines.

dans mon cas si, car je souhaite séparer les réseaux IP, donc routage


Et il y a un peu de contradiction dans ce que tu dis. Tu dis que tu
as ajouté une route manuellement (statique), mais ensuite tu te
surprend de ne pas avoir de routes via un protocol de routage
Dynamique. C'est possible de router des routes statiques, mais je
crois que ça commence à compliquer les choses pour rien pour toi. Fais
bien attention. Si tu veux absolument avoir les 2 routers dans des
plages IP différentes, et que tu n'as pas de protocol de routage
dynamique, et que tu ajoute des routes statiques, n'oublie pas de les
mettre dans les deux sens!!


Vu la complexité du réseau, un protocole de routage est superflux,
quelques routes rajoutées à bon escient sur les routeurs devraient
fonctionner tout aussi bien. En l'occurence, j'ai rajouté sur le routeur
A (passerelle par défaut) une route permettant aux hosts du LAN
d'atteindre le réseau IP du wifi. Les hosts wifi, eux, savent joindre
directement le LAN, puisque le routeur wifi a ajouté "naturellement" à sa
table de routage les bonnes routes pour aller de A vers B !

Ton fameux paquet ICMP peut être qu'il se
rend, mais qu'il ne revient pas, simplement car de B vers A il n'y a
aucune route. Mais si j'étais toi j'oublirais cette option. Oublie le
routage, cest n'est pas nécessaire.


non, un coup de tcpdump m'a montré qu'il n'est même pas émis par le
routeur

DONC EN RÉSUMÉ, pas besoin de routage pour faire ce que tu veux faire.
Ton router B ne sert que d'ACCESS POINT simplement. Et en bout de
ligne, autant les PC sur le lan cablé sur A que les PC wi-fi sur B
auront des addresses IP dans le même sous réseau et possiblement du
même serveur DHCP (soit buit-in dans le router B ou dans LINUX/dhcpd
mais attention de ne pas avoir les 2 en meme temps!!) et suite a ceci
tu pourras pigner sans probleme tout ce beau monde.

non ! B n'est pas un AP, c'est un routeur, dont une de ses interfaces est

wifi (en fait, B est aussi un hosts linux, avec une carte Prism54)

Bonne chance.
SVP tiens nous au courant des développements.
Et N'hésite pas a poster un petit diagrame de ton montage!

oula, en ASCII art, ca va etre coton !


PS: Sur linux, je te suggère SHOREWALL pour faire un tel travail
(firewall, pontage, routage, nat, etc, etc etc. Tres puissant.)

et moi je te suggères Debian :)




Bonjour,

Avant d'aller plus loins, faite ce test.

Directement à partir du router A (debian - 192.168.1.254) faite votre
ping en direction de 192.168.1.100. Es-ce fonctionnel? Si NON, oubliez
le routage pour l'instant, il n'est pas en cause. Si il s'agit bien de
deux routers (et non pas switch niveau 3 ou de combo Router/Switch
ex:LinkSys) alors assurez vous d'avoir un cable croisé entre les deux, à
moins qu'ils soient reliés via une switch ou hub.

Pour vous assurez que votre ping sort bien via ETH0, spécifié
l'interface à utiliser dans votre commande Ex: ping -I eth0
192.168.1.100.

Suite à un ping infructueux, passez la commande ARP. (postez nous le
résultat). Vous devriez avoir quelque chose qui ressemble à ceci:

Address HWtype HWaddress Flags Mask Iface
192.168.1.100 ether 00:XX:XX:XX:XX:98 C eth0

Si vous avez la mention INCOMPLETE, ce n'est pas bon signe.


Également passé la commande ROUTE sur votre Debian. Montrez nous le
résultat ici. Vous deviez y retrouver quelque chose comme ceci:

Destination Gateway Genmask Flags Metric Ref Use Iface
....
....
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

Si vous n'avez pas ceci, il n'est pas étonnant que votre TCPDUMP sur
ETHO n'aie rien retourné.





-=Si le tout ping bien, passons à autre chose=-


- Quels est le modèle de router de B ?
- Utilisez vous des access-list?
- Utilisez vous des Route Map?
- Avez vous utilisé un DÉBUG afin de valider les logs ?
- Avez vous fais un TRACEROUTE pour vous assurer que le paquet utilise
bien le gateway? (en conjonction avec les routes)
- Voyez vous votre route dans la table de routage?




Et que voulez vous dire quand vous dites:

"les tables de routages des stations de travail soient mises à jour
dynamiquement."

Une station standard possède une table de routage limité, statique,
généralement composée du default gateway et des routes de ses interfaces
locales. Les postes de travail ne participent pas dans l'échange des
tables de routage dynamique comme RIP, EIGRP ou OSPF. C'est le travail
du router, de votre gateway.


Et que voulez vous dire par: "Les hosts wifi, eux, savent joindre
directement le LAN, puisque le routeur wifi a ajouté "naturellement" à
sa table de routage les bonnes routes pour aller de A vers B !"

Naturellement? C'est "dynamiquement" ou "statiquement"... mais pas
naturellement. SVP élaborer sur ce que vous vouliez vraiement dire.


Et pourquoi me dites vous dans votre dernier message que:

"non ! B n'est pas un AP, c'est un routeur!"

alors quand dans le premier message vous nous dites:

"un routeur B (faisant office de point d'accès WiFi)"


SVP soyez rigoureux dans vos informations et fournissez nous un maximum
de données.

Aidez nous à vous aider.

NOTE: Dites nous, quelle est votre motivation à diviser votre en deux
sous-réseau IP? Es-ce un montage commercial? Avez vous beaucoup de
postes de travail? Problème de performance? Quel est le but recherché?

Merci.


Avatar
Eric Belhomme
SiO wrote in
news:4Azwh.6897$:

Avant d'aller plus loins, faite ce test.

Directement à partir du router A (debian - 192.168.1.254) faite votre
ping en direction de 192.168.1.100. Es-ce fonctionnel? Si NON,
oubliez le routage pour l'instant, il n'est pas en cause. Si il
s'agit bien de deux routers (et non pas switch niveau 3 ou de combo
Router/Switch ex:LinkSys) alors assurez vous d'avoir un cable croisé
entre les deux, à moins qu'ils soient reliés via une switch ou hub.

evidemment que ca pinge !


- Quels est le modèle de router de B ?


déjà répondu : le routeur B est un host Linux Debian avec un carte wifi
capable de fonctionner en mode master

eth0 -> ethernet 192.168.1.100/24
eth1 -> wifi 192.168.2.254/24

route par défaut 192.168.1.254 (routeur A)
routes ajoutée automatiquement

192.168.1.0/24 dev eth0
192.168.2.0/24 dev eth1

Et que voulez vous dire quand vous dites:

"les tables de routages des stations de travail soient mises à jour
dynamiquement."

Une station standard possède une table de routage limité, statique,
généralement composée du default gateway et des routes de ses
interfaces locales. Les postes de travail ne participent pas dans
l'échange des tables de routage dynamique comme RIP, EIGRP ou OSPF.
C'est le travail du router, de votre gateway.

non, mes stations de travail tourent sous windows 2k pro, windows XP, et

linux.
Tous ces OS savent modifier leurs tables de routage à la réception de
message icmp_redirect

Et que voulez vous dire par: "Les hosts wifi, eux, savent joindre
directement le LAN, puisque le routeur wifi a ajouté "naturellement" à
sa table de routage les bonnes routes pour aller de A vers B !"

192.168.1.0/24 dev eth0

192.168.2.0/24 dev eth1

Naturellement? C'est "dynamiquement" ou "statiquement"... mais pas
naturellement. SVP élaborer sur ce que vous vouliez vraiement dire.

naturellement car la route est crée automatiquement par la pile ip et

découle de la configuration des interfaces réseaux en présence sur le
routeur B

Et pourquoi me dites vous dans votre dernier message que:

"non ! B n'est pas un AP, c'est un routeur!"

alors quand dans le premier message vous nous dites:

"un routeur B (faisant office de point d'accès WiFi)"

parce que c'est le cas ! B possède 2 interfaces (dont l'une est wifi)

sur 2 réseaux IP diférents, donc il route...
J'insistait sur ce point (peut être maladroitement) car vous semblez
présuposer qu'un AP wifi est forcément en mode bridge ethernet, ce dont
je ne veux pas !

SVP soyez rigoureux dans vos informations et fournissez nous un
maximum de données.

Vous avez toutes les billes


NOTE: Dites nous, quelle est votre motivation à diviser votre en deux
sous-réseau IP? Es-ce un montage commercial? Avez vous beaucoup de
postes de travail? Problème de performance? Quel est le but recherché?

ne pas mélanger mes choux et mes carottes...


--
Rico

Avatar
Pascal Hambourg
Salut,


sur un réseau, j'ai 2 routeurs :

- un routeur A (passerelle par défaut) est la porte de sortie vers
internet, sous Linux (Debian Sarge)


Quelle version de noyau ?

Il me semble pourtant que dans cette configuration, le message
icmp_redirect devrait être émis, il doit donc être bloqué quelque part,
mais où ???


Y a-t-il du filtrage iptables à état en OUTPUT sur l'interface LAN ?
Avec les noyaux < 2.4.29, certains messages d'erreur ICMP émis
localement sont à tort classés par le suivi de connexion dans l'état
INVALID au lieu de RELATED.

Avatar
Eric Belhomme
Pascal Hambourg wrote in news:epv3ke$136t$1
@biggoron.nerim.net:

Quelle version de noyau ?

2.6.18.2 vanilla compillé depuis les sources officielles de kernel.org


Y a-t-il du filtrage iptables à état en OUTPUT sur l'interface LAN ?


oui, mais l'icmp est explicitement autorisé sur l'interface lan, dans les
toutes permières règles sur les tables INPUT/OUTPUT

Avec les noyaux < 2.4.29, certains messages d'erreur ICMP émis
localement sont à tort classés par le suivi de connexion dans l'état
INVALID au lieu de RELATED.

je pense pas que ce soit applicable à mon kernel...


--
Rico

Avatar
SiO
Eric Belhomme wrote:
SiO wrote in
news:4Azwh.6897$:

Avant d'aller plus loins, faite ce test.

Directement à partir du router A (debian - 192.168.1.254) faite votre
ping en direction de 192.168.1.100. Es-ce fonctionnel? Si NON,
oubliez le routage pour l'instant, il n'est pas en cause. Si il
s'agit bien de deux routers (et non pas switch niveau 3 ou de combo
Router/Switch ex:LinkSys) alors assurez vous d'avoir un cable croisé
entre les deux, à moins qu'ils soient reliés via une switch ou hub.

evidemment que ca pinge !


- Quels est le modèle de router de B ?


déjà répondu : le routeur B est un host Linux Debian avec un carte wifi
capable de fonctionner en mode master

eth0 -> ethernet 192.168.1.100/24
eth1 -> wifi 192.168.2.254/24

route par défaut 192.168.1.254 (routeur A)
routes ajoutée automatiquement

192.168.1.0/24 dev eth0
192.168.2.0/24 dev eth1

Et que voulez vous dire quand vous dites:

"les tables de routages des stations de travail soient mises à jour
dynamiquement."

Une station standard possède une table de routage limité, statique,
généralement composée du default gateway et des routes de ses
interfaces locales. Les postes de travail ne participent pas dans
l'échange des tables de routage dynamique comme RIP, EIGRP ou OSPF.
C'est le travail du router, de votre gateway.

non, mes stations de travail tourent sous windows 2k pro, windows XP, et

linux.
Tous ces OS savent modifier leurs tables de routage à la réception de
message icmp_redirect

Et que voulez vous dire par: "Les hosts wifi, eux, savent joindre
directement le LAN, puisque le routeur wifi a ajouté "naturellement" à
sa table de routage les bonnes routes pour aller de A vers B !"

192.168.1.0/24 dev eth0

192.168.2.0/24 dev eth1

Naturellement? C'est "dynamiquement" ou "statiquement"... mais pas
naturellement. SVP élaborer sur ce que vous vouliez vraiement dire.

naturellement car la route est crée automatiquement par la pile ip et

découle de la configuration des interfaces réseaux en présence sur le
routeur B

Et pourquoi me dites vous dans votre dernier message que:

"non ! B n'est pas un AP, c'est un routeur!"

alors quand dans le premier message vous nous dites:

"un routeur B (faisant office de point d'accès WiFi)"

parce que c'est le cas ! B possède 2 interfaces (dont l'une est wifi)

sur 2 réseaux IP diférents, donc il route...
J'insistait sur ce point (peut être maladroitement) car vous semblez
présuposer qu'un AP wifi est forcément en mode bridge ethernet, ce dont
je ne veux pas !

SVP soyez rigoureux dans vos informations et fournissez nous un
maximum de données.

Vous avez toutes les billes


NOTE: Dites nous, quelle est votre motivation à diviser votre en deux
sous-réseau IP? Es-ce un montage commercial? Avez vous beaucoup de
postes de travail? Problème de performance? Quel est le but recherché?

ne pas mélanger mes choux et mes carottes...




Ok, merci des éclaircissements. Maintentant c'est clair.


Internet---<A>---LAN---<B>---WiFi


Dans A, il y a une route que vous avez ajouté qui stipule:

DST MSK
192.168.2.0 255.255.255.0 via 192.168.1.100 (eth0)


Dans un montage comme celui-ci, même si le ICMP Redirect ne serait pas
activé, le trafique devrait quand même se rendre à destination, bien que
d'une façon non optimisée (un hop en trop). Es-ce le cas?

Si ce n'est pas le cas, oublions les paramêtres ICMP redirect pour
l'instant, le problème est ailleur. Le ICMP redirect optimisera la route
prise par le data, mais il n'est pas critique au fonctionnement du routage.

**Un bon test à faire pour cerner que le problème est sur A ou sur B:

Sur un des ordinateurs du LAN (XP, 2000 etc..) pour fins de test,
ajouter une route manuellement.

192.168.2.0/24 VIA 192.168.1.100

Ensuite pinger l'interface WI-FI de B ou autres postes sur le lan WIFI.
Vous devriez avoir une réponse.

Si vous n'obtenez pas de réponses, le problème est localisé sur B.
Si le ping fonctionne, alors la partie routage de B est fonctionnel,
donc concentrez vous sur A.

Ceci au moins concentrera vos efforts au bon endroit :)

Tenez nous au courant des développements.

Bonne chance.
Merci!


Avatar
Pascal Hambourg

Quelle version de noyau ?


2.6.18.2 vanilla compillé depuis les sources officielles de kernel.org

Avec les noyaux < 2.4.29, certains messages d'erreur ICMP émis
localement sont à tort classés par le suivi de connexion dans l'état
INVALID au lieu de RELATED.


je pense pas que ce soit applicable à mon kernel...


Non, en effet. La seule autre raison pour ne pas envoyer d'ICMP Redirect
est quand les paquets ont subi un DNAT pour des raisons évidentes, mais
je doute que ce soit le cas ici.