Qué es una VPN
Una VPN crea conectividad lógica sobre una red subyacente que no controlas completamente. Puede conectar sedes, usuarios remotos o redes virtuales. «VPN» describe el resultado; existen múltiples tecnologías para conseguirlo.
IPsec es una familia de estándares que proporciona servicios de seguridad a nivel IP. No todas las VPN usan IPsec y usar IPsec no implica necesariamente una topología site-to-site.
Arquitectura IPsec
RFC 4301 define la arquitectura de seguridad para IP. IPsec aplica políticas y Security Associations (SA) para decidir qué tráfico se protege, cómo y con qué parámetros.
Una SA es unidireccional; una comunicación bidireccional protegida implica asociaciones en ambos sentidos. Cada asociación incluye algoritmos, claves, identificadores y otros parámetros negociados o configurados.
ESP y AH
Encapsulating Security Payload (ESP) es el mecanismo usado habitualmente para confidencialidad y también puede proporcionar integridad/autenticación según el conjunto criptográfico. Authentication Header (AH) proporciona integridad/autenticación pero no cifrado del payload y es mucho menos común en despliegues modernos.
No memorices «IPsec = cifrado» como regla absoluta: la arquitectura define servicios y políticas; la configuración concreta determina qué protección se aplica.
Modo transporte y modo túnel
En modo transporte, la cabecera IP original sigue siendo la cabecera exterior y se protege principalmente la carga de la capa superior. En modo túnel, el paquete IP original queda encapsulado dentro de un nuevo paquete IP protegido.
Las VPN site-to-site suelen usar modo túnel porque conectan redes detrás de gateways, aunque el diseño concreto depende de la plataforma y caso de uso.
IKEv2 y negociación
Internet Key Exchange version 2 (IKEv2), definido en RFC 7296, autentica peers, negocia parámetros criptográficos y establece las asociaciones necesarias. En lugar de configurar manualmente todas las claves de IPsec, IKE gestiona ese intercambio de forma protocolizada.
La autenticación puede basarse en claves precompartidas o certificados, entre otros métodos soportados. Certificados simplifican determinados escenarios a escala, pero requieren una PKI bien operada.
Traffic selectors y políticas
Los peers deben acordar qué tráfico pertenece al túnel. En implementaciones policy-based esto suele expresarse mediante selectores/políticas; en diseños route-based aparece una interfaz lógica y el routing decide qué tráfico entra al túnel.
«Route-based» y «policy-based» son modelos de implementación comunes, no dos protocolos IPsec diferentes. La interoperabilidad depende de cómo cada producto mapea rutas, políticas y selectores.
NAT Traversal
ESP no usa puertos TCP/UDP normales, y NAT puede interferir con ciertos campos protegidos. NAT Traversal encapsula ESP sobre UDP, típicamente puerto 4500, para atravesar dispositivos NAT. RFC 3948 describe la encapsulación UDP de paquetes IPsec ESP.
En troubleshooting, comprobar si existe NAT entre peers ayuda a interpretar por qué IKE puede empezar correctamente pero el tráfico protegido no fluye como se esperaba.
MTU, overhead y fragmentación
IPsec añade cabeceras y, en modo túnel, una nueva cabecera IP. Ese overhead reduce el espacio disponible para el payload dentro de una MTU fija. Si se ignora, pueden aparecer fragmentación, pérdidas o problemas de Path MTU Discovery.
En TCP a veces se ajusta MSS en bordes del túnel para evitar paquetes demasiado grandes, pero el valor correcto depende del encapsulado real. Mide en vez de copiar números genéricos.
Routing y VPN
Una VPN necesita conectividad subyacente entre peers antes de poder establecerse. Después, el tráfico protegido también necesita una decisión de routing coherente hacia el túnel o política correspondiente.
Problemas de rutas solapadas, retorno asimétrico o default routes incorrectas pueden parecer fallos criptográficos. Revisa el cluster de routing junto con IPsec.
ACL, firewall y NAT alrededor del túnel
IKE, ESP y NAT-T deben atravesar políticas intermedias. Además, muchos diseños requieren exenciones o un orden específico respecto a NAT. La secuencia exacta de procesamiento es específica de cada plataforma.
No asumas que una ACL «interesante» de un producto es idéntica a una ACL de filtrado. Consulta la documentación del fabricante y observa contadores/SA activas.
Troubleshooting por fases
Divide el diagnóstico: 1) ¿los peers tienen conectividad IP? 2) ¿se establece IKE? 3) ¿existen SA IPsec? 4) ¿los selectores/rutas incluyen el tráfico esperado? 5) ¿aumentan contadores al enviar tráfico? 6) ¿hay retorno? 7) ¿MTU o políticas intermedias causan pérdidas?
Esta secuencia evita cambiar criptografía cuando el problema real es routing o ACL. Usa troubleshooting y capturas autorizadas cuando sea necesario.
Seguridad operativa
Usa algoritmos y parámetros vigentes recomendados por el fabricante y políticas de tu organización; retira suites obsoletas; protege claves privadas y secretos precompartidos; rota credenciales y controla quién puede cambiar políticas.
Un túnel cifrado conecta zonas. Eso puede ampliar el alcance de una intrusión si las redes a ambos lados confían demasiado entre sí, por lo que segmentación y ACL siguen siendo necesarias.
Referencias
RFC 4301 define la arquitectura IPsec; RFC 4303, ESP; RFC 7296, IKEv2; RFC 3948, UDP encapsulation para NAT Traversal. Las implementaciones concretas añaden interfaces, perfiles y sintaxis propias.
Siguiente paso
Continúa con seguridad de Capa 2 y vuelve a seguridad de red para integrar VPN dentro de segmentación, identidad y observabilidad.
Ejemplo de flujo site-to-site
Imagina dos sedes con redes 10.10.0.0/16 y 10.20.0.0/16. Los gateways primero necesitan reachability pública entre sus direcciones externas. Después IKE autentica peers y negocia parámetros; se crean SA IPsec y el tráfico que coincide con rutas/selectores se encapsula mediante ESP.
En el extremo remoto se valida y desencapsula el paquete original, que vuelve a entrar en el proceso de routing hacia la LAN. Para la respuesta ocurre el proceso inverso. Si cualquiera de las dos sedes carece de ruta de retorno o selecciona un tráfico diferente, el túnel puede aparecer «up» mientras la aplicación sigue fallando.
Rekey, lifetimes y detección de peer
Las SA no son permanentes. Tienen lifetimes y se renegocian para renovar material criptográfico. Durante troubleshooting es importante distinguir un fallo inicial de negociación de un problema que aparece durante rekey.
Las implementaciones también usan mecanismos para detectar peers no disponibles, habitualmente asociados a IKE. Los nombres y temporizadores varían. Si un túnel cae periódicamente, correlaciona logs de IKE, expiraciones, conectividad WAN y cambios de NAT en lugar de asumir que el cifrado «se rompe solo».
Interoperabilidad entre fabricantes
Dos equipos compatibles con IPsec pueden fallar si no coinciden proposals, autenticación, identificadores, selectores o tratamiento de fragmentación. Compara los parámetros negociados realmente, no sólo los configurados en la interfaz gráfica.
Los logs de IKE suelen indicar la fase en la que se produce el desacuerdo. Mantén relojes sincronizados y recopila mensajes de ambos extremos para evitar interpretar sólo una mitad de la negociación.
Monitorizar salud del túnel
En operación conviene observar estado de IKE, número de SA, bytes/paquetes protegidos, renegociaciones, errores de autenticación y cambios de peer. Un túnel «up» con contadores inmóviles indica un problema distinto de un túnel que no consigue negociar.
Correlaciona estas métricas con routing, pérdida WAN y logs de firewall. La monitorización histórica permite distinguir un incidente puntual de un patrón que coincide con rekey, cambios de dirección pública o saturación.