Le 05/06/2019 à 20:41, David Ponzone a écrit :
Tu penses bien que j’ai déjà envisagé ça et fait toutes les permutations
possibles.
En fait maintenant je sais: si le paquet a comme IP source 10.11.X.Y, l’ACL est
correctement matchée.
Si c’est 10.15.X.Y, ça matche pas le deny, et c’est NATé.
Je pense que j’ai fait le tour, ça ne peut être qu’un bug: That’s Cisco after
all.
Le 5 juin 2019 à 09:45, Paul Rolland (ポール・ロラン) <rol+fr...@witbe.net> a écrit :
Hello,
On Wed, 5 Jun 2019 09:17:31 +0200
David Ponzone <david.ponz...@gmail.com> wrote:
ip access-list extended test
deny ip 10.11.0.0 0.0.255.255 10.11.0.0 0.0.255.255 -> celle-ci exclut
bien le traffic à ne pas NATer deny ip 10.11.0.0 0.0.255.255 10.15.0.0
0.0.255.255 -> celle-ci ne fait pas son job deny ip 10.15.0.0
0.0.255.255 10.11.0.0 0.0.255.255 -> non plus deny ip 10.15.0.0
0.0.255.255 10.15.0.0 0.0.255.255 -> non plus permit ip 10.11.0.0
0.0.255.255 any permit ip 10.15.0.0 0.0.255.255 any
Ca sent l'ACL qui ne fait que le premier deny... Jamais vu ca... mais du
coup, tu peux essayer ca :
ip access-list extended test
deny ip 10.11.0.0 0.4.255.255 10.11.0.0 0.4.255.255
permit ip 10.11.0.0 0.0.255.255 any
permit ip 10.15.0.0 0.0.255.255 any
pour matcher tous tes deny en une seule ACL (tu as de la chance, c'est
possible dans ton cas).
OK, c'est pas propre, c'est complique a lire, mais normalement, chez Cisco,
ca marche...
Paul
Hello,
Une piste à défaut d'en savoir plus sur la config: essayer une ACL numérotée à la place de
l'ACL nommée.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
