Nous avons mis en place deux tunnels, l'un pour acheminer le trafic vers 10.195.XX / 16 et l'autre tunnel doit acheminer le trafic vers 10.195.XX / 32, qui est inclus dans la plage du premier tunnel, et quand le trafic doit passer le deuxième tunnel ne va que sur le premier. Différentes listes de contrôle d'accès ont été configurées pour ce scénario comme suit:
MAIN ACL
IPsec policy XX 1 isakmp
security acl 3000
ike-peer XX
proposal XX
tunnel local XX
SPECIFIC TUNNEL
ipsec policy XX 2 isakmp
security acl 3001
ike-peer XX
proposal XX
tunnel local XX
MAIN ACL
acl number 3000
rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255
SPECIFIC ACL
acl number 3001
rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0
Étant donné que le deuxième IP / 32 est déjà inclus dans le premier, / 16, il correspondra toujours au premier ACL, ce qui correspondra au premier tunnel.
Il y a eu une tentative de bloquer le trafic pour le premier tunnel avec l'espoir qu'il ira sur le second:
MAIN ACL
acl number 3000
rule 5 deny ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0
rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255
Après cela, le trafic ne fonctionnera plus du tout, car il correspondra à la politique de refus et ne fonctionnera plus du tout.
La solution est la suivante:
Pour que cela soit fait et pour fonctionner correctement, une modification de la stratégie IPSec ISAKMP la séquence doit être changée entre eux et la logique est la suivante.
MAIN tunnel:
ipsec policy XX 2 isakmp
security acl 3000
ike-peer XX
proposal XX
tunnel local XX
SPECIFIC TUNNEL
ipsec policy XX 1 isakmp
security acl 3001
ike-peer XX
proposal XX
tunnel local XX
MAIN ACL
acl number 3000
rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255
SPECIFIC ACL
acl number 3001
rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0
La logique est que le trafic correspond clairement au premier tunnel car l'IP / 32 est déjà inclus dans le / 16, donc il correspondra et ne passera pas à la SEQUENCE suivante.
Si nous refusons de la première ACL que IP sur la première séquence, encore une fois, il correspondra et ne se poursuivra pas sur la prochaine séquence
Si nous modifions la SÉQUENCE entre eux comme indiqué ci-dessus, sur l'ACL, il ne sera permis que l'IP / 32 spécifique, les autres IP de la plage / 16 présentées ne le seront pas, donc passera à la SÉQUENCE suivante et fera correspondre l'ACL là.
Si une correspondance est effectuée sur une liste de contrôle d'accès spécifique à partir d'une séquence ISAKMP, elle ne passera pas à la séquence suivante.