De acuerdo

La política IPSEC coincide con el túnel incorrecto

152 0 0 0 0

Tenemos dos túneles configurados, uno para reenviar el tráfico a 10.195.XX/16 y el otro túnel debe reenviar el tráfico a 10.195.XX/32, que está incluido en el rango desde el primer túnel, y cuándo debe pasar el tráfico. el segundo túnel va solo en el primero. Se configuraron diferentes ACL para este escenario de la siguiente manera:


Túnel principal:

IPsec policy XX 1 isakmp

security acl 3000

ike-peer XX

proposal XX

tunnel local XX


TÚNEL ESPECÍFICO

ipsec policy XX 2 isakmp

security acl 3001

ike-peer XX

proposal XX

tunnel local XX


ACL PRINCIPAL

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


ACL ESPECÍFICO

acl number 3001

rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0


Como el segundo IP/32 ya está incluido en el primero, /16, siempre coincidirá con el primer ACL, lo que dará como resultado el primer túnel.


Hubo un intento de bloquear el tráfico para el primer túnel con la esperanza de que continúe en el segundo:


ACL PRINCIPAL

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


Una vez hecho esto, el tráfico no funcionaría en absoluto, ya que coincidirá con la política de denegación y ya no funcionará.


La solución es la siguiente:


Para que esto se haga y funcione correctamente, un cambio en la secuencia ISAKMP de la política IPSec debe cambiarse entre ellos y la lógica es la siguiente.


Túnel principal:

ipsec policy XX 2 isakmp

security acl 3000

ike-peer XX

proposal XX

tunnel local XX


TÚNEL ESPECÍFICO

ipsec policy XX 1 isakmp

security acl 3001

ike-peer XX

proposal XX

tunnel local XX


ACL PRINCIPAL

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


ACL ESPECÍFICO

acl number 3001

rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0


La lógica es que el tráfico coincide claramente con el primer túnel porque el IP/32 ya está incluido en el /16, por lo que coincidirá y no pasará a la siguiente SECUENCIA.


Si negamos desde la primera ACL esa IP en la primera secuencia, nuevamente coincidirá y no continuará en la próxima SECUENCIA


Si cambiamos la SECUENCIA entre ellos como se muestra anteriormente, en la ACL solo se permitirá la IP/32 específica, las otras IPs del rango /16 presentado no lo harán, por lo que llegarán a la próxima SECUENCIA y coincidirán con la ACL.


Si se realiza una coincidencia en una ACL específica de una secuencia ISAKMP, no se procederá a la siguiente secuencia.


  • x
  • convención:

Comentar

Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse
Responder

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”

My Followers

¡Ingresa y disfruta de todos los beneficios para los miembros!

Inicia sesión

Bloquear
¿Estás seguro de bloquear a este usuario?
Los usuarios en lista negra no pueden comentar tus publicaciones,no pueden mencionarte,no pueden enviarte mensajes privados.
Recordatorio
Agrega tu número de teléfono para obtener un bono de invitación.