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 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
