Consejos y trucos: ¿por qué utilizar un identificador de proxy VPN?

¿Recuerdas nuestro dilema de la semana pasada, donde teníamos superposición de subredes sobre un túnel VPN IPSec? Estábamos buscando una manera de que las redes de pares se comunicaran. ID de proxy al rescate. Si tiene un cortafuegos de Palo Alto Networks que trabaja con una VPN basada en políticas peer Supporting, necesitará IDS de proxy.

 

La semana pasada la discusión de la semana (DotW) es la ayuda con los IDS de proxy, pero vamos a hablar más acerca de los IDS proxy VPN y por qué es importante utilizarlos.

 

Cuando estamos hablando de túneles VPN IPSec, si está configurando el cortafuegos de Palo Alto Networks para trabajar con un par que admita VPN basada en políticas, debe definir IDS de proxy. Los dispositivos que admiten VPN basada en políticas utilizan reglas o políticas de seguridad específicas o listas de acceso (direcciones de origen, direcciones de destino y puertos) para permitir tráfico interesante a través de un túnel IPSec. Estas reglas se hacen referencia durante la negociación de la fase 2 de modo rápido/IKE, y se intercambian como ID de proxy en el primer o segundo mensaje del proceso.

 

Por lo tanto, si está configurando el cortafuegos de Palo Alto Networks para trabajar con un par VPN basado en directivas, para una negociación de fase 2 satisfactoria, debe definir el identificador de proxy para que la configuración de ambos pares sea idéntica. Si el identificador de proxy no está configurado, ya que el cortafuegos de Palo Alto Networks admite VPN basada en rutas, los valores predeterminados utilizados como ID de proxy son IP de origen: 0.0.0.0/0, IP de destino: 0.0.0.0/0 y aplicación: any; y cuando estos valores se intercambian con el par, el resultado es un error al configurar la conexión VPN.

 

Ahora, echemos un vistazo a la ventana de ID de proxy y las opciones:

Dentro de la sección de ID de proxy, (ubicado dentro de la WebGUI-red > túneles IPSec > Seleccione un túnel > pestaña IDs proxy), verá muchas opciones:

• ID de proxy: haga clic en Agregar e introduzca un nombre para identificar el proxy. Puede ser cualquier nombre. Si sólo se utilizan números, no se aceptará.
• Local : permite introducir una dirección IP o subred en el formato ip_address/Mask (por ejemplo, 10.1.2.1/24).
• Remoto (reMote ): si lo requiere el interlocutor, introduzca una dirección IP o subred en el formato ip_address/Mask (por ejemplo, 10.1.1.1/24).
• Protocolo -especifique el protocolo y los números de puerto para los puertos locales y remotos:
• Número (Number): permite especificar el número de protocolo (utilizado para la interoperabilidad con dispositivos de terceros).
• Any : permite el tráfico TCP y/o UDP.
• TCP : especifique los números de puerto TCP local y remoto.
• UDP : especifique los números de puerto UDP locales y remotos.

Nota: cada ID de proxy se cuenta como un túnel VPN, y por lo tanto se calcula hacia la capacidad del túnel VPN IPSec del firewall. (Ejemplo: site-toiSite IPSec VPN Tunnel Limit-PA-3020-1000, PA-2050-100, PA-200-25)

 

La ventaja con los IDs de proxy es la capacidad de obtener granular con números de protocolo o números de puerto TCP/UDP si usted tiene tráfico específico que desea viajar por el túnel VPN sólo. Los IDS proxy permiten fácilmente tal granularidad.

 

Debido a que hay 2 versiones de IKE, el comportamiento con IDS de proxy es diferente:
-con IKEv1, los dispositivos de Palo Alto Networks sólo admiten la coincidencia exacta de proxy-ID. En el caso de que los ID de proxy del mismo no coincidan, entonces habrá problemas con la VPN trabajando correctamente.
-Con IKEv2, hay un selector de tráfico de soporte que se estrecha cuando la configuración de ID de proxy es diferente en las dos puertas de enlace VPN, sólo la opción implementada se describe en los casos de uso a continuación.

 

Casos de uso IKEv2

Consulte a continuación una lista de casos de uso con IPSec y IKEv2 que pueden ayudar a explicar muchas configuraciones VPN de IPSec y cómo utilizar correctamente los ID de proxy.

 

Ejemplo: hay dos gateways VPN: a y B. IKE la negociación es iniciada por VPN GW-A. i = iniciador, r = responder

 

Suponga VPN GW-a selector de tráfico definido TSi-a/TSr-a; El VPN GW-b tiene ajuste para el selector de tráfico TSi-b/TSr-b. TSR-a es lo mismo que TSR-b, por lo que puede ser ignorado. TSi-a puede ser diferente de TSi-b.

 

A. TSI-a es igual que TSI-b, por ejemplo, ambos son 5.10.11.0/24.

Se espera: entonces no se requiere un estrechamiento, el comportamiento es el mismo que el caso de ID de proxy IKEv1 existente. El tráfico no sería capaz de pasar, en este ejemplo, NAT se requeriría para permitir la comunicación adecuada.

 

VPN GW-a: enviar: TSi: 5.10.11.0-5.10.11.255

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [resultado final]

 

Esta solución se detalla en el artículo DotW aquí:

Ayuda con el identificador de proxy

B. TSI-a es superconjunto de TSI- B:

B1. VPN GW-a propone TSi-a = 5.10.0.0/16; En VPN GW-b: TSi-b = 5.10.11.0/24.

 

i. El túnel se trae para arriba sin tráfico (por ejemplo, durante la inicialización o por el comando de la prueba).

 

Esperado: como el respondedor, VPN GW-b responde a VPN GW-a con 5.10.11.0/24. El GW-a de VPN debe aceptarlo y crear el niño SA.

 

VPN GW-a: enviar: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [enangostado al subconjunto común]

 

II. UN host detrás de VPN GW-a (por ejemplo, host IP 5.10.11.2) intenta sacar el túnel.

 

Esperado: como el respondedor, VPN GW-b responde a VPN GW-a con 5.10.11.0/24. El GW-a de VPN debe aceptarlo y crear el niño SA. El tráfico debe pasar.

 

VPN GW-a: sending: TSI: 5.10.11.2; 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [enangostado al subconjunto común]

 

Si somos el iniciador, no enviamos el primer selector de tráfico específico (5.10.11.2) en la carga de IKE.

Como respondedor, debemos ser capaces de manejar el peer que envía el selector de tráfico específico. También se reducirá el selector de tráfico al subconjunto común.

 

III. UN host detrás de VPN GW-a (por ejemplo, host IP 5.10.6.2) intenta sacar el túnel.

Esperado: como el respondedor, VPN GW-b responde a VPN GW-a con 5.10.11.0/24. El GW-a de VPN debe aceptarlo y crear el niño SA.

 

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [enangostado al subconjunto común]

 

Si somos el iniciador, no enviamos el primer selector de tráfico específico (5.10.6.2) en la carga de IKE.

 

Como respondedor, reduciremos el selector de tráfico al subconjunto común. Si la carga útil de TS recibida contiene el selector de tráfico específico, aunque está fuera de la directiva local, seguimos haciendo el enangostar pero ignoramos el selector de tráfico específico por RFC 5996.

 

B2. VPN GW-a propone TSi-a = 5.10.0.0/16; En VPN GW-b: hay más de una entradas definidas: TSi-b = 5.10.11.0/24 + 5.10.12.0/24.

 

i. El túnel es criado sin tráfico.

 

Strongswan admite varias entradas por selector de tráfico. Tan strongswan se puede utilizar para fijar como VPN GW-b. Si Panos es GW-b, necesitamos configurar múltiples proxy-IDS.

 

VPN GW-a: enviar: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [Panos: el subconjunto común de la primera entrada coincidente]

 

Lo anterior muestra el resultado de Panos como el respondedor (VPN GW-b). Responde a VPN GW-a con una de las entradas: 5.10.11.0/24 o 5.10.12.0/24 (la primera entrada basada en el orden en "Mostrar túnel VPN", orden alfabético de nombre completo del túnel).

 

Algunos proveedores (como VPN GW-b) pueden devolver un TS con ambas entradas (5.10.11.0-5.10.11.255 + 5.10.12.0-5.10.12.255), pero sólo instalamos la primera entrada.

 

II. UN host detrás de VPN GW-a (p.ej. Host IP 5.10.11.2) intenta sacar el túnel.

Esperado: como el respondedor, VPN GW-b responde a VPN GW-a con 5.10.11.0/24. El tráfico debe pasar.

 

VPN GW-a: Send: TSi: 5.10.11.2; 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [PAN-OS: el subconjunto común de la primera entrada coincidente, prefiriendo la política que puede cubrir 5.10.11.2]

 

Si somos el iniciador, no enviamos el primer selector de tráfico específico (5.10.11.2) en la carga de IKE.

 

Si somos el respondedor, buscamos todos los proxy-ID configurados hasta que una entrada puede cubrir el selector de tráfico específico y se puede enangostar o ajustar exactamente. Si el selector de tráfico específico no puede estar cubierto por el subconjunto común, seguimos intentando hacer el estrechamiento.

 

III. Después del paso II, otro host detrás de VPN GW-a (p.ej. Host IP 5.10.12.2) intenta llegar al otro extremo de la VPN.

Esperado: como el tráfico no coincide con el túnel VPN previamente creado, se negociará otro SA de IPSec.

 

VPN GW-a: Send: TSi: 5.10.12.2; 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.12.0-5.10.12.255 [Panos: el subconjunto común de la primera entrada coincidente, prefiriendo la política que puede cubrir 5.10.12.2]

 

En este momento, los túneles de VPN para ambos proxy-ID están arriba y el tráfico que pasa.

 

Es posible que algún proveedor no inicie otra negociación IKE. Envían los paquetes usando el túnel existente establecido en el paso II aunque no empareje 5.10.12.2. Necesitamos revisar todo el proceso de negociación del túnel para analizar este tipo de comportamiento.

 

IV. UN host detrás de VPN GW-a (por ejemplo, host IP 5.10.6.2) intenta llegar al otro extremo de la VPN (sin el paso II y III).

 

Esperado: porque no hay SA que empareja en VPN GW-a, intenta negociar con VPN GW-b. La respuesta puede ser dependiente de la implementación.

 

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.12.0-5.10.12.255 [Panos: el subconjunto común de la primera entrada coincidente]

 

v. Después del paso III, un host detrás de VPN GW-a (por ejemplo, host IP 5.10.6.2) intenta llegar al otro extremo de la VPN.

 

El iniciador podría utilizar un túnel previamente establecido para reenviar el tráfico al mismo nivel. Elegir qué túnel puede depender del proveedor.

 

B3. Para VPN GW-b que no admite el estrechamiento del selector de tráfico

 

Algunos dispositivos VPN no admiten el estrechamiento del selector de tráfico, p.ej. Cisco IOS 15,0 responde NO_PROPOSAL_CHOSEN en este caso.

 

El túnel no se puede establecer y la configuración debe cambiarse.

 

C. TSi-a es subconjunto de TSr-b:

VPN GW-a propone TSi-a = 5.10.11.0/24; En VPN GW-b: TSr-b = 5.10.0.0/16.

 

i. El túnel es criado sin tráfico.

 

Esperado: VPN GW-b responde 5.10.11.0/24. El túnel se establece utilizando la parte común de los selectores de tráfico (5.10.11.0/24).

VPN GW-a: enviar: TSi: 5.10.11.0-5.10.11.255

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [resultado final-el subconjunto común]

 

II. UN host detrás de VPN GW-a (p.ej. Host IP 5.10.11.2) intenta sacar el túnel.

 

Se espera: se establece un túnel con selector de tráfico 5.10.11.0/24. El tráfico debe ser capaz de pasar.

VPN GW-a: Send: TSi: 5.10.11.2; 5.10.11.0-5.10.11.255

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [resultado final]

 

Si somos el iniciador, no enviamos el primer selector de tráfico específico (5.10.11.2) en la carga de IKE.

 

Como respondedor, debemos ser capaces de manejar el peer que envía el selector de tráfico específico. Vamos a elegir el selector de tráfico del iniciador, ya que es más pequeño.

 

III. UN host detrás de VPN GW-a (por ejemplo, host IP 5.10.6.2) trata de sacar el túnel

 

Espera:

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.11.0-5.10.11.255

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [resultado final]

 

Cuando pan-os es el iniciador, si no hay ID de proxy o identificador de proxy único definido en la misma interfaz de túnel, el túnel será negociado como arriba y el tráfico será enviado a través del túnel.

 

En caso de múltiples proxy ID, seguiremos verificando otro proxy ID (Tunnel ID) para ver si hay una coincidencia. Si no hay coincidencia, entonces el último proxy-ID se utiliza para negociar el túnel y enviar el tráfico. Este es el comportamiento definido en varias asociaciones de fase 2 de IPsec.

 

Si pan-os es el respondedor y otro proveedor que ejecuta la directiva VPN es el iniciador, es posible que no inicie la negociación del túnel, ya que el paquete está fuera del intervalo de su directiva local. Si se inicia la negociación del túnel, se utilizará el selector de tráfico del iniciador, ya que es más estrecho.

 

D. existe una superposición entre TSi-a y TSr-b.

VPN GW-a propone TSi-a = 5.10.0.0/16; En VPN GW-b: TSr-b = 5.10.11.0/24 + 5.9.0.0/24.

i. El túnel es criado sin tráfico.

 

Esperado: VPN GW-b responde 5.10.11.0/24. El túnel se establece utilizando la parte común de los selectores de tráfico (5.10.11.0/24).

VPN GW-a: enviar: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [resultado final-el subconjunto solapado]

 

II. UN host detrás de VPN GW-a (p.ej. Host IP 5.10.11.2) intenta sacar el túnel.

 

Se espera: se establece un túnel con selector de tráfico 5.10.11.0/24. El tráfico debe ser capaz de pasar.

VPN GW-a: Send: TSi: 5.10.11.2, 5.10.0.0-5.10.255.255 

VPN GW-b: respuesta: TSi: 5.10.11.0-5.10.11.255 [subconjunto común]

 

Si somos el iniciador, no enviamos el primer selector de tráfico específico (5.10.11.2) en la carga de IKE.

 

Como respondedor, debemos ser capaces de manejar el peer que envía el selector de tráfico específico. También se reducirá el selector de tráfico al subconjunto común.

 

III. UN host detrás de VPN GW-a (por ejemplo, host IP 5.10.12.2-dentro de la política de VPN GW-a, pero fuera de la política de la VPN GW-b) trata de sacar el túnel.

 

Espera:

VPN GW-a: enviar: TSi: 5.10.12.2, 5.10.0.0-5.10.255.255
VPN GW-b: respuesta: TSI: 5.10.11.0-5.10.11.255 [subconjunto común]

 

Si Panos es el iniciador: el respondedor no puede encontrar un rango que sea útil para 5.10.12.2 por lo que devuelve el rango común (5.10.11.0/24). El túnel puede ser establecido. No enviamos el selector de tráfico específico.

 

Basándonos en nuestro comportamiento existente definido en varias asociaciones de fase 2 de IPSec, el paquete se enviará a través de este túnel, pero podría ser eliminado por el respondedor. Es posible que el túnel VPN de envío no lo note.

 

IV. UN host detrás de VPN GW-a (por ejemplo, host IP 5.9.0.2-dentro de la política de VPN GW-b, pero fuera de la Directiva para VPN GW-a) trata de sacar el túnel.

 

Esperado:
VPN GW-a: Send: TSI: 5.9.0.2, 5.10.0.0-5.10.255.255
VPN GW-b: reply: TSI: 5.10.11.0-5.10.11.255 [subconjunto común]

 

Si el iniciador es pan-os, el ID de proxy 0.0.0.0/0 (si no hay un ID de proxy definido) o el último ID de proxy (en caso de que haya varios ID de proxy definidos en la interfaz del túnel) se utiliza en TSI.

 

El tráfico podría ser descargado por el respondedor (basado en políticas VPN), ya que viola el reducido TS.
Si el iniciador está haciendo una estricta comprobación de la directiva VPN (no pan-os), entonces la negociación de IKE no se puede desencadenar a medida que infringe la directiva VPN.

 

Eso concluye los trucos y consejos. Espero que hayas aprendido algo de este artículo.

 

Como siempre, damos la bienvenida a todos los comentarios y sugerencias a continuación.

 

¡ Manténganse seguros!

Joe Delio