Procesamiento de tráfico de paso a través de IPSec en el cortafuegos de Palo Alto Networks

Procesamiento de tráfico de paso a través de IPSec en el cortafuegos de Palo Alto Networks

61865
Created On 09/26/18 13:48 PM - Last Modified 11/19/19 04:34 AM


Resolution


 Como se explica en el documento https://Live.paloaltonetworks.com/docs/DOC-5819, los números de puerto para la creación de la sesión IPSec se derivan de los valores SPI que intercambian los homólogos IPSec remotos durante la fase 2 del establecimiento de túneles. Pero este método sólo se puede aplicar en caso de que uno de los pares de IPSec sea el propio cortafuegos o, en otras palabras, sólo si el túnel IPSec se termina en el cortafuegos.

 

En el caso del tráfico IPSec de paso, donde el cortafuegos de Palo Alto Networks es sólo un dispositivo intermedio entre dos pares de IPSec, es prácticamente imposible crear una sesión basada en valores SPI negociados, ya que IKE Phase 2 está encriptado y su contenido es no visible para el firewall.

 

Dado que los valores SPI no se pueden ver de antemano, para el tráfico de paso a través de IPSec, el cortafuegos de Palo Alto Networks crea una sesión utilizando el valor genérico 20033 para el puerto de origen y de destino. En el ejemplo siguiente, se puede ver que los puertos de origen y destino de los flujos de C2S y s2c tienen el mismo valor, 20033:

 

admin @ VM-300 > Mostrar sesión ID 791

sesión 791

C2S flujo:
Fuente: 192.168.0.11 [Trust]
DST: 129.187.7.11
proto: 50
deporte: 20033 dport: 20033
Estado: activo tipo: flujo
src usuario: desconocido
DST uso r: desconocido

s2c flujo:
Fuente: 129.187.7.11 [Untrust]
DST: 192.168.0.11
proto: 50
deporte: 20033 dport: 20033
Estado: activo tipo: flujo
src usuario: desconocido
DST usuario: desconocido

hora de Inicio: Jue 10 11:58 de junio: 59 2015 timeout: 3600 sec tiempo de vida: 3142 sec número total de bytes (C2S): 1080 total de bytes (s2c): 1014 layer7 cuenta de paquetes (C2S): 8 layer7 de paquetes (s2c): 5 vsys: vsys1 aplicación: IPsec-ESP regla: any-any sesión que se registrará al final: sesión verdadera en la sesión de edad: verdadera sesión actualizada por ha peer: false layer7 Processing: filtrado de URL completado habilitado: URL verdadera categoría: cualquier sesión mediante SYN-cookies: sesión falsa terminado en host: sesión falsa atraviesa túnel: falsa sesión portal cautivo: falso ingreso interfaz: ethernet1/2 salida interfaz: ethernet1/1 sesión QoS regla: N/A (clase 4) Tracker etapa l7proc: CTD App no tiene decodificador < C46 > fin-razón: Unknown

 

En la serie PA-7000 y PA-5200, debido a una diferencia arquitectónica, utilizamos una técnica diferente para la creación de sesiones de tráfico de paso de IPSec. En estas plataformas, los puertos de sesión se derivan de nuevo basándose en los valores SPI, como se describe en https://Live.paloaltonetworks.com/T5/Learning-articles/what-do-The-Port-numbers-in-an-IPsec-ESP-SESS... , pero como los valores SPI no se conocen en Advance Firewall crea una sesión como el tráfico ESP real llega al firewall. El tener cada flujo (client2server, server2client) de un solo túnel IPSec utilizando un valor SPI único implica que Firewall crea dos sesiones IPSec independientes para un túnel IPSec, uno por cada dirección. Esto significa que las directivas de seguridad deben configurarse para permitir el tráfico ESP de paso en ambas direcciones en las plataformas de la serie PA-7000 y PA-5200.



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClpXCAS&lang=es&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language