Site-to-Site VPN con Certificados

Contenido complementario

Este tema no está en las notas de tus cursos que tengo; está completado con conocimiento general de PAN-OS. Los valores de IP y nombres son de ejemplo (no del laboratorio). Compáralo con lo que viste en la lección y corrígelo si difiere.

Resumen

En el Site-to-Site VPN Estático los dos firewalls se autentican con una clave precompartida (PSK): una contraseña que ambos conocen. Es simple, pero tiene problemas: la clave hay que guardarla y cambiarla en cada sitio, y si tienes muchos túneles, la gestión se vuelve difícil e insegura. La alternativa es autenticar con certificados digitales: cada firewall presenta un certificado emitido por una CA que el otro firewall reconoce y en la que confía. No hay una contraseña compartida que filtrar, se pueden revocar certificados individuales y escala mucho mejor.
El túnel IPsec es el mismo; lo único que cambia es la autenticación de la Fase 1. Hace falta: una CA (la raíz) en la que ambos confíen, un certificado de dispositivo en cada firewall (con su clave privada), un Certificate Profile que le diga al firewall en qué CA confiar para validar al peer, y en el IKE Gateway se elige Certificate en lugar de Pre-Shared Key. Esta nota explica ese proceso y los errores típicos (identificadores, CA no confiable, certificados vencidos).

Requisitos previos

• El túnel IPsec funcionando con PSK, o al menos el modelo claro (ver IPsec Fundamentals y Site-to-Site VPN Estático)
• Una CA que emita certificados para los dos firewalls (CA interna de Microsoft, otra, o el firewall como CA para laboratorio) (ver Certificates y PKI)
• La CA raíz (y las intermedias) importadas en ambos firewalls y marcadas como Trusted Root CA
• Un certificado en cada firewall con su clave privada, con Common Name o SAN que lo identifique (por ejemplo su FQDN o su IP)
• La hora correcta (NTP) en ambos firewalls: un certificado “aún no válido” o vencido por desfase de hora hace fallar la Fase 1
• Alcanzabilidad de CRL u OCSP si vas a validar revocación

Cómo cambia la autenticación

sequenceDiagram
    participant A as Firewall A (cert A)
    participant B as Firewall B (cert B)
    A->>B: Certificado A (firmado por la CA)
    B->>B: Valida la firma con la CA raíz (Certificate Profile)<br/>comprueba fechas y revocación
    B->>A: Certificado B (firmado por la CA)
    A->>A: Valida la firma con la CA raíz (Certificate Profile)
    Note over A,B: Autenticación mutua correcta: sigue la Fase 1 y la Fase 2 igual que con PSK

Aspecto	PSK	Certificados
Qué comparten los peers	Una contraseña	Una CA de confianza
Gestión con muchos túneles	Difícil	Escala bien
Revocar un peer	Cambiar la PSK en todos	Revocar solo su certificado
Qué se configura en el IKE Gateway	Pre-Shared Key	Certificate + Certificate Profile
Riesgo principal	Filtración de la clave	Certificado vencido o CA no confiable

Configuración (Ejemplo)

Mismo escenario que Site-to-Site VPN Estático: PA-15 (23.1.2.15) y PA-16 (23.1.2.16). Solo se muestra lo que cambia; el resto (Tunnel Interface, perfiles de cifrado, IPsec Tunnel, rutas, NAT y políticas) es igual.

1. Importar la CA raíz y confiar en ella (en ambos)

1. Device > Certificate Management > Certificates > Import: la CA raíz (sin clave privada), Certificate Name Corp_Root_CA.
2. Ábrela y marca Trusted Root CA. OK.
3. Si hay CA intermedias, impórtalas también.
4. Los pasos detallados están en Certificates y PKI.

2. Certificado del firewall con clave privada (en cada uno)

1. Device > Certificate Management > Certificates > Generate.
2. Certificate Type Local, Certificate Name PA15-VPN-Cert, Common Name pa15.ogit.local (o la IP).
3. Signed By External Authority (CSR), Algorithm RSA, Number of Bits 2048, Digest sha256.
4. Certificate Attributes > Add: Hostname pa15.ogit.local y/o IP 23.1.2.15 (se usan como SAN para identificar al peer).
5. Generate, exporta la CSR, fírmala en la CA (plantilla de servidor web o la que defina tu CA con uso de autenticación de cliente y servidor), descarga el certificado en Base64 e importa con el mismo nombre.
6. El estado debe ser valid.
7. Repite en PA-16 con pa16.ogit.local y 23.1.2.16.

Extended Key Usage

Algunos peers exigen que el certificado tenga los usos Server Authentication y Client Authentication. Una plantilla de servidor web suele incluir ambos; confírmalo con tu CA si el peer rechaza el certificado.

3. Certificate Profile

1. Device > Certificate Management > Certificate Profile > Add.
2. Name VPN-Peers-CP.
3. Username Field None (no se usa para VPN de sitio a sitio).
4. CA Certificates > Add: Corp_Root_CA (y las intermedias).
5. Use CRL / Use OCSP: marca según tu infraestructura, con sus timeouts. Si el CRL no es alcanzable y lo marcas como obligatorio, la Fase 1 falla.
6. OK.

4. IKE Gateway con certificados

1. Network > Network Profiles > IKE Gateways > edita (o crea) GW-PA16.
2. Pestaña General: Authentication Certificate.
3. Local Certificate PA15-VPN-Cert.
4. Local Identification: tipo FQDN (hostname) y valor pa15.ogit.local (debe coincidir con el SAN o Common Name del certificado local).
5. Peer Identification: tipo FQDN (hostname) y valor pa16.ogit.local (debe coincidir con el certificado del peer).
6. Certificate Profile VPN-Peers-CP.
7. Opcional: marca Strict Validation of Peer’s Extended Key Use si tu política lo exige.
8. OK y Commit.

En PA-16: Local Certificate PA16-VPN-Cert, Local Identification pa16.ogit.local, Peer Identification pa15.ogit.local.

set network ike gateway GW-PA16 authentication certificate local-certificate name PA15-VPN-Cert
set network ike gateway GW-PA16 authentication certificate certificate-profile VPN-Peers-CP

Si un comando no coincide con tu versión, usa Tab o ?.

5. Iniciar y probar

1. test vpn ike-sa gateway GW-PA16 y test vpn ipsec-sa tunnel Tunnel-to-PA16.
2. Network > IPSec Tunnels: Status en verde.
3. ping source 172.16.0.1 host 172.16.0.2, y desde la LAN a la LAN remota.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Device > Certificate Management > Certificates	El certificado local valid, la CA con Trusted Root CA	Si está pendiente o inválido, repite la importación con el mismo nombre
show clock	Hora actual correcta en ambos firewalls	Si difiere, arregla NTP (ver Initial Setup y Management Plane)
Network > IPSec Tunnels	Phase 1 y Tunnel Info en verde	Phase 1 rojo: ver el log
show vpn ike-sa	IKE SA establecida con el peer	Si no hay, lee less mp-log ikemgr.log
less mp-log ikemgr.log	Mensajes sobre certificados: “cert validation failed”, “no matching ID”	El mensaje indica si falla la cadena, la fecha, el ID o la revocación
show vpn ipsec-sa	IPsec SA activa	Si falta, mira Fase 2
show vpn flow	Contadores de encap/decap subiendo	Si no suben, revisa rutas y políticas
Monitor > Logs > System (subtype eq vpn)	Eventos de autenticación del peer	Útil para ver el motivo exacto del rechazo
Device > Certificate Management > Certificate Profile	CA correcta y CRL/OCSP configurados	Si el CRL no alcanza, desmarca o arregla la conectividad

Errores comunes

Fase 1 falla con error de certificado

• Causa: el firewall no confía en la CA que firmó el certificado del peer, o la cadena está incompleta (falta una CA intermedia).
• Revisa: less mp-log ikemgr.log y que la CA (y las intermedias) estén importadas con Trusted Root CA.
• Solución: importa la cadena completa en ambos firewalls y agrégala al Certificate Profile.

”No matching peer ID” o fallo de identificación

• Causa: el Peer Identification no coincide con el SAN o Common Name del certificado del peer.
• Solución: usa el mismo valor (FQDN o IP) que lleva el certificado, o ajusta el tipo de identificador.

Certificado vencido o “aún no válido”

• Causa: el certificado venció, o la hora del firewall está mal.
• Solución: corrige NTP; renueva el certificado antes de que venza (anota las fechas).

La validación de revocación falla

• Causa: el firewall no alcanza el CRL/OCSP y el perfil lo trata como error.
• Solución: asegura la salida hacia el CRL/OCSP, o ajusta las opciones de timeout/estado desconocido (según tu política de seguridad).

El peer rechaza mi certificado por el uso de clave

• Causa: el certificado no tiene Extended Key Usage compatible.
• Solución: pide a la CA una plantilla con Server y Client Authentication.

Fase 1 verde pero no hay tráfico

• Causa: igual que en el túnel con PSK: rutas, NAT o políticas.
• Solución: revisa los pasos de Site-to-Site VPN Estático.

Cambié el certificado y el túnel no se levanta

• Causa: la IKE SA antigua sigue activa o el IKE Gateway aún apunta al certificado anterior.
• Solución: selecciona el nuevo certificado en el IKE Gateway, haz commit y limpia las SA (clear vpn ike-sa gateway GW-PA16).