La stratégie IPSEC correspond au mauvais tunnel

16 0 0 0

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.


  • x
  • Standard:

Commentaire

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.
Connectez-vous pour participer à la communication et au partage

Connectez-vous pour participer à la communication et au partage

S'identifier