Usando IPsec a través de NAT

Las Asociaciones de Seguridad ESP (SA) son unidireccionales. Por lo tanto, para comunicarse bidireccionalmente se requieren dos SA, en cada extremo una SA es para el tráfico entrante y otra para el tráfico saliente (y viceversa en el otro extremo).

Estas SA se identifican por el protocolo (ESP / AH), la dirección IP de destino y un identificador de 32 bits llamado Índice de Parámetros de Seguridad (SPI). Y esa es toda la información contenida en cada paquete ESP (protocolo, dirección de destino y SPI de destino).

Por lo tanto, a diferencia de los puertos de origen y destino que forman parte de los encabezados UDP, solo un SPI está contenido en un encabezado ESP. Por lo tanto, para un enrutador NAT no es posible saber a qué host detrás del NAT tiene que reenviar los paquetes ESP entrantes. Si nunca hubiera tráfico saliente, no sabría que incluso si ambas SPI estuvieran contenidas en el encabezado de ESP, ya que no conoce estas SPI, que se comunican encriptadas a través del protocolo de intercambio de claves de Internet (IKE) cuando se establecieron las SA .

Lo que los enrutadores NAT suelen tener es una característica llamada "paso a través de IPsec". El enrutador NAT detectará el tráfico IKE y luego reenviará cualquier paquete ESP simple entre los dos hosts que se comunicaron a través de IKE. Sin embargo, esto solo funciona para un cliente VPN detrás de NAT que se comunica con una dirección IP de servidor particular. Con más de un cliente, el NAT nuevamente no sabría a qué cliente reenviar un paquete ESP entrante en particular.

Para admitir este escenario, los encabezados UDP se agregan a los paquetes ESP. Esto permite que el NAT trate estos paquetes ESP-in-UDP como cualquier otro paquete UDP. Dado que se utilizan los mismos puertos que ya están en uso para IKE, la NAT en realidad ya tiene asignaciones de puertos cuando los pares comienzan a intercambiar tráfico ESP (a menos que el enrutador NAT realice una inspección profunda, no puede distinguir este tráfico del tráfico IKE).

Para separar los paquetes IKE de los paquetes ESP encapsulados con UDP en el destinatario, el primero tiene cuatro bytes cero agregados entre UDP y el encabezado IKE (llamado marcador no ESP), que es donde el SPI se almacena en los paquetes ESP (que no puede ser 0 si RFC 3948 está implementado). Este formato de paquete modificado también es la razón por la que se usa un puerto diferente para este tráfico (4500).

básicamente funciona para ambos modos IPsec (túnel / transporte). Sin embargo, hay algunos problemas (descritos más detalladamente en las consideraciones de seguridad de RFC 3948 ):

• Cuando se usa el modo de túnel, las direcciones IP de dos clientes detrás de diferentes NAT podrían ser las mismas, lo que causaría SA / políticas duplicadas en la puerta de enlace. Para evitar que las puertas de enlace usualmente asignen direcciones IP virtuales de subredes designadas a clientes móviles (roadwarriors) durante la negociación IKE o por medio de DHCP.

• Con el modo de transporte, varios clientes detrás del mismo NAT son problemáticos. Si todos utilizan el mismo protocolo y los selectores de puerto, las políticas de IPsec se superpondrán (ya que todas comparten la misma IP pública) y podría ser difícil para la pasarela decidir qué SA usar para enviar el tráfico. En algún escenario, los puertos utilizados para la encapsulación UDP se pueden usar para solucionar este problema (eso es lo que el complemento de connmark trata de hacer). También es problemático la situación cuando no todos los clientes detrás de NAT usan IPsec para comunicarse con una puerta de enlace (consulte la RFC para obtener más detalles).

AH es inherentemente incompatible con NAT, ya que su Valor de verificación de integridad (ICV) incluye el encabezado de IP externo (solo se excluyen algunos campos). Por lo tanto, cualquier modificación a las direcciones IP por un NAT invalidará el ICV.

El problema es el modo de túnel IPsec, que utiliza el protocolo ESP. ESP no funciona con NAT por dos razones:

1. ESP crea una suma de comprobación que cubre todo el paquete, incluidas las direcciones. Si el NAT cambia las direcciones, la verificación de integridad fallará y el paquete se descartará.
2. ESP también no usa puertos. Por lo tanto, NAT no podrá agregarlos a su base de datos de traducción. (Esto no impide la comunicación, pero sí la complica)

La solución es encapsular el tráfico ESP en UDP. El NAT puede cambiar las direcciones UDP porque no se confía en la suma de comprobación de UDP. El uso de udp / 4500 también significa que el tráfico ESP se limitará a un solo puerto, lo que permitirá que el NAT lo agregue al diccionario de traducción.

Para obtener más detalles, consulte RFC 3947 y RFC 3948