Configurar IPsec Site-to-Site con certificados en Sophos Firewall
Una preshared key compartida se configura rápidamente para un único túnel entre sedes. Con varios firewalls o requisitos de PKI más estrictos, un digital certificate suele ser más fácil de controlar: cada lado posee su propia clave privada, los peers confían en las CA emisoras y un certificado concreto puede renovarse o revocarse de forma selectiva.
Este procedimiento muestra una conexión IPsec policy-based entre dos Sophos Firewall. Complementa la guía general para configurar una VPN IPsec Site-to-Site. Los diseños route-based requieren además planificar routing y XFRM, pero el procedimiento de confianza y certificados descrito aquí sigue siendo el mismo.
Procedimiento seguro en ocho pasos
- Documentar los roles del túnel, las redes, el perfil IKEv2 y las Certificate IDs.
- Comprobar en ambos firewalls un backup de configuración y un acceso administrativo funcional.
- Exportar la CA emisora de cada firewall e importarla en la contraparte.
- Generar en cada firewall un certificado local firmado independiente con una Certificate ID única.
- Exportar únicamente el certificado público e importarlo en la contraparte como Remote Certificate.
- Crear IPsec policy-based con Authentication type > Digital certificate en ambos lados.
- Revisar de forma restrictiva Device Access y las reglas de firewall generadas automáticamente.
- Validar estado del túnel, confianza del certificado, logs y tráfico real en ambas direcciones.
⚠️ El archivo de clave privada permanece en el firewall donde se generó el certificado. Para el intercambio de confianza solo se transfieren certificados de CA y certificados públicos del peer. Sin un segundo acceso administrativo probado, un backup y una vía de recuperación documentada, no se desactivan túneles PSK existentes ni se sustituyen certificados productivos.
Ejemplo y valores de planificación
El ejemplo conecta la sede central SF1 con la sucursal SF2:
SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN
- WAN de SF1:
172.10.10.1 - WAN de SF2:
172.20.20.1 - Certificado de SF1:
SF1_Certificate - Certificado de SF2:
SF2_Certificate - Certificate ID de SF1:
172.10.10.1 - Certificate ID de SF2:
172.20.20.1
Estas direcciones y nombres son valores de documentación. En el entorno real se utilizan las direcciones WAN, los objetos de red y un esquema de ID único para toda la organización. La Certificate ID debe permanecer asociada a la contraparte correspondiente y no debe confundirse con el nombre mostrado ni con un SAN arbitrario.
Establecer confianza mutua entre CA
Primero se revisa y descarga en SF1 la CA emisora desde Certificates > Certificate authorities. Si el ejemplo utiliza la CA local Default, el archivo exportado recibe un nombre inequívoco como Head_Office_Default.pem. En SF2 se importa bajo Certificates > Certificate authorities > Add, por ejemplo como SF1_CA.
Después se repite el procedimiento en sentido contrario: se exporta la CA de SF2, se le asigna un nombre inequívoco como Branch_Office_Default.pem y se importa en SF1, por ejemplo como SF2_CA.
Los nombres de archivo solo facilitan la administración. Lo importante son Subject, Issuer, fingerprint, validez y la cadena de CA correcta. Estos valores se comparan mediante un canal independiente antes de la importación. Gestionar certificados en Sophos Firewall explica las tareas generales de CA, certificados y asignación a servicios.
La CA integrada
Defaultno debe regenerarse como tarea secundaria. La regeneración cambia el trust anchor y puede afectar a otros portales, servicios TLS y peers IPsec. Para una CA empresarial se importa en su lugar toda su cadena de confianza.
Preparar certificados locales y remotos
Crear el certificado propio en SF1
En SF1 se crea un certificado en Certificates > Certificates > Add > Generate locally-signed certificate. El ejemplo de Sophos utiliza RSA, una Key length de 2048 y SHA-256. Estos valores no sustituyen la política de criptografía y validez de la organización; el perfil IPsec elegido y ambos peers deben admitirlos.
En Subject Alternative Names (SANs) > Advanced settings se selecciona una Certificate ID. Se admiten DNS, IP address, Email y DER ASN1 DN [X.509]. El ejemplo utiliza IP address con 172.10.10.1.
Con DER ASN1 DN [X.509], Sophos utiliza el Subject de la CA emisora. En este caso, DNS names e IP address deben quedar vacíos en los SAN porque, según Sophos, los valores adicionales provocan un conflicto durante la autenticación IPsec.
Después de Save, se comprueban validez, Issuer, Certificate ID y la existencia de la clave privada. Se exporta el certificado público, se cambia la extensión a .cer si es necesario y se importa en SF2 mediante Certificates > Certificates > Add > Upload certificate como SF1_Certificate. La columna Trusted de la contraparte debe confirmar la confianza mediante SF1_CA.
Crear el certificado propio en SF2
En SF2 se repite el procedimiento con una clave privada independiente. En el ejemplo, el certificado se llama SF2_Certificate, la Certificate ID es 172.20.20.1 y la CA emisora es la CA local de SF2.
El certificado público se importa en SF1. Allí, Trusted debe estar confirmado mediante la SF2_CA importada previamente. Cada firewall tiene ahora exactamente dos roles distintos:
- Local certificate: certificado propio con la clave privada.
- Remote certificate: certificado público de la contraparte, validado por su CA.
Una marca de confianza verde demuestra la cadena del certificado, pero no un túnel funcional. Validez, Certificate ID, perfil IKE, gateway y redes también deben coincidir. La revocación y distribución de CRL son un proceso operativo separado; véase Certificate Revocation Lists en Sophos Firewall.
Crear la conexión IPsec en ambos lados
En Site-to-site VPN > IPsec > Add se crean dos conexiones compatibles. En el ejemplo, la sede central espera a la sucursal:
- Connection type:
Policy-based - Gateway type:
Respond only - Profile:
Head office (IKEv2)o un clon de perfil propio coordinado - Authentication type:
Digital certificate - Local certificate:
SF1_Certificate - Remote certificate:
SF2_Certificate - Listening interface: WAN de
SF1 - Local subnet:
SF1_LAN - Gateway address: dirección WAN de
SF2 - Remote subnet:
SF2_LAN
En la sucursal se invierten los roles:
- Gateway type:
Initiate the connection - Profile:
Branch office (IKEv2)o el perfil propio correspondiente - Local certificate:
SF2_Certificate - Remote certificate:
SF1_Certificate - Local subnet:
SF2_LAN - Gateway address: dirección WAN de
SF1 - Remote subnet:
SF1_LAN
Los perfiles se planifican como un par. Comprender los perfiles IPsec en Sophos Firewall explica cómo interactúan IKEv2, fase 1, fase 2, PFS, lifetimes y DPD.
Comprobar Device Access y reglas de firewall
El lado con Gateway type > Respond only debe poder aceptar conexiones IPsec en la ruta WAN prevista. En Administration > Device access se activa IPsec solo para la zona WAN realmente necesaria o se utiliza una excepción Local Service ACL restrictiva para direcciones conocidas del peer. SSO, certificados o un algoritmo IPsec robusto no justifican un acceso amplio a WebAdmin o SSH. Configurar Device Access de forma segura en Sophos Firewall explica la planificación de ACL.
Si Create firewall rule está activado, SFOS crea reglas VPN automáticas. Estas reglas son un punto de partida. En Rules and policies > Firewall rules se revisan orden, dirección, redes de origen y destino, servicios y logging, y se limitan a la necesidad real. Crear reglas de firewall en Sophos Firewall explica la validación de reglas.
Ping/Ping6 para la zona VPN solo es necesario cuando se utiliza deliberadamente una dirección del propio firewall como destino de prueba. Este servicio local no debe abrirse de forma general para una prueba end-to-end normal entre hosts detrás de los firewalls.
Validar túnel y certificados
La validación separa cuatro niveles:
- En Site-to-site VPN > IPsec, la conexión y el túnel están activos.
- Ambos firewalls muestran los Local y Remote Certificate esperados, periodos de validez correctos y un Issuer de confianza.
- Un host de prueba real alcanza el servicio previsto en la red remota y después se prueba el sentido contrario.
- Firewall Rule ID, Packet Capture y los logs de IPsec confirman la misma ruta y las mismas marcas de tiempo.
strongswan.log es el principal punto de partida para errores de IKE y certificados. charon.log, ipsec_monitor.log y el log específico de la conexión en /log/ipsec_conn/ aportan más evidencias. Solucionar problemas de IPsec en Sophos Firewall cubre el procedimiento completo de diagnóstico.
Acotar errores según el síntoma
El túnel permanece down
Primero se confirma que Local certificate y Remote certificate están realmente invertidos de forma correcta en ambos lados. Después se comprueban Certificate ID, Gateway address, perfil IKEv2, validez y cadena de confianza. Un certificado de peer importado sin la CA correspondiente no es una identidad de confianza.
El certificado aparece como Trusted, pero falla la autenticación
Trusted solo confirma la cadena. Con DER ASN1 DN [X.509], ningún valor SAN de DNS o IP adicional debe reemplazar el identificador. Con los otros tipos de ID, valor, tipo y contraparte esperada deben coincidir exactamente. En strongswan.log se comparan los ID realmente ofrecidos y esperados para el mismo intento de conexión.
El túnel está verde, pero no circula tráfico
La autenticación mediante certificado ya se ha completado. Ahora se comprueban subredes locales y remotas, reglas VPN automáticas, Rule ID, NAT, ruta de retorno y servicio de destino real. Regenerar certificados sin una prueba concreta solo oculta el estado original en este caso.
El certificado está a punto de caducar
El nuevo certificado local se prepara en paralelo, se transfiere su parte pública a la contraparte y allí se confirma la confianza. Solo durante una ventana de mantenimiento se cambian de forma controlada Local certificate y Remote certificate en ambos lados. Los certificados y CA antiguos se mantienen disponibles hasta completar la validación bidireccional y solo después se eliminan o revocan.
Rollback y operación
Antes del cambio se documentan ambas conexiones IPsec, nombres de certificados, fingerprints, Certificate IDs, periodos de validez y el orden actual de las reglas. Un backup de configuración de Sophos Firewall forma parte de la preparación, pero no sustituye un acceso directo de recuperación al firewall.
Si falla la validación, se restauran las asignaciones de certificados utilizadas previamente o se reactiva el túnel PSK que todavía esté disponible. Los nuevos certificados de peer o CA importados solo se eliminan después de comprobar que ninguna otra conexión o servicio los utiliza. Después se vuelven a probar el estado del túnel y un flujo real.
En operación, los certificados necesitan un responsable, monitorización del vencimiento y una ventana de renovación planificada. La primera alerta debe dejar tiempo suficiente para emisión, distribución de confianza, prueba paralela y rollback. Sustituir un certificado únicamente el día de su caducidad convierte un mantenimiento planificado en una caída de VPN.