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 los ID locales y remotos.
- Comprobar en ambos firewalls la hora, 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 e ID explícitos de los peers 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 10.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 10.20.20.0/24 SF2-LAN
- WAN de SF1:
198.51.100.10 - WAN de SF2:
203.0.113.20 - Certificado de SF1:
SF1_Certificate - Certificado de SF2:
SF2_Certificate - Certificate ID de SF1:
198.51.100.10 - Certificate ID de SF2:
203.0.113.20
Las direcciones WAN pertenecen a los rangos de documentación RFC 5737 y las LAN son privadas. 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.
Antes de crear los certificados, se comprueba la sincronización NTP en Administration > Time. Una hora incorrecta puede hacer fallar la importación y la comprobación de validez. Este procedimiento IPsec también requiere certificados RSA: SFOS 22 admite ECDSA para otros usos, pero no para conexiones IPsec.
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, con el propósito Validation only.
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. Si se utiliza una CA subordinada, también debe estar presente su CA raíz. 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. No se selecciona una CA pública como Remote CA certificate: Sophos advierte de que un atacante podría usar un certificado válido emitido por esa CA para obtener acceso no autorizado.
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. Se seleccionan RSA, una Key length acorde con la política propia y un Secure hash permitido; RSA 2048 y SHA-256 son los valores del ejemplo de Sophos. Valid from y Valid until se definen con margen suficiente para una renovación controlada. SFOS utiliza un año de forma predeterminada, pero la política de la organización determina la validez real.
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 198.51.100.10. Sophos permite aquí cualquier dirección IP válida; se elige un identificador estable cuyo tipo y valor se reflejen en la configuración del peer.
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 203.0.113.20 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. SFOS añade automáticamente los certificados locales firmados localmente que se revoquen a su CRL predeterminada. El peer solo conoce la revocación después de transferirle la CRL actual e importarla bajo Certificates > Certificate revocation lists > Add. Para certificados emitidos externamente, se importa la CRL de la CA externa. 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 - Remote CA certificate:
SF2_CA - Listening interface: WAN de
SF1 - Local subnet:
SF1_LAN - Gateway address: dirección WAN de
SF2 - Remote subnet:
SF2_LAN - Local ID type / Local ID:
IP address/198.51.100.10 - Remote ID type / Remote ID:
IP address/203.0.113.20
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 - Remote CA certificate:
SF1_CA - Local subnet:
SF2_LAN - Gateway address: dirección WAN de
SF1 - Remote subnet:
SF1_LAN - Local ID type / Local ID:
IP address/203.0.113.20 - Remote ID type / Remote ID:
IP address/198.51.100.10
Los perfiles y los ID se planifican como pares: el Local ID de un lado corresponde al Remote ID del otro. Los ID DNS, IP y de correo electrónico no tienen que resolverse como direcciones de gateway, pero su tipo y valor deben coincidir exactamente. Para DER ASN1 DN [X.509], se introduce como Remote ID el Distinguished Name del certificado del peer. 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 una regla entrante y otra saliente en la parte superior del grupo Automatic VPN rules. 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.
/log/strongswan.log es el principal punto de partida para errores de IKE y certificados. /log/charon.log registra el servicio VPN IPsec y /log/ipsec_monitor.log supervisa el servicio IPsec; /log/ipsec_conn/ipsec_<connectionname>.log recoge las acciones específicas de la conexión. /log/dgd.log corresponde al failover de enlaces o VPN. 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. También se comprueba que esté seleccionado el Remote CA certificate correcto. 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, Local y Remote ID deben reflejarse por tipo y valor. En /log/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.
En un clúster HA, los cambios se realizan en el Primary actual y se espera a que SFOS sincronice la configuración del firewall con el Auxiliary. Tras la sincronización, primero se comprueban la selección de certificados y el túnel en el Primary, y después se valida un failover HA planificado con tráfico real. Un backup HA solo puede restaurarse en el Primary actual y la restauración lo reinicia sin failover. Es una vía de recuperación con interrupción, no un sustituto rápido para restablecer la asignación de certificados anterior.