IPsec PA a Cisco

Contenido complementario

Este tema no está en las notas de tus cursos que tengo; está completado con conocimiento general de PAN-OS y de Cisco IOS. Los valores de IP, nombres y los comandos de Cisco son de ejemplo y pueden variar según el modelo y la versión: verifícalos en tu equipo. Compáralo con lo que viste en la lección y corrígelo si difiere.

Resumen

En la vida real no siempre el otro extremo es otro Palo Alto: muchas oficinas tienen routers o firewalls Cisco. IPsec es un estándar, así que un túnel entre ambos es posible, pero hay una diferencia clave: el Palo Alto trabaja con VPN basada en rutas (el tráfico entra al túnel porque una ruta lo apunta a la Tunnel Interface), mientras que un Cisco clásico con crypto map trabaja basado en políticas (una ACL define qué tráfico “interesante” se cifra). Para que ambos se entiendan en la Fase 2, deben coincidir las redes que se cifran: en el Palo Alto eso se logra con Proxy IDs.
Esta nota arma el túnel entre un Palo Alto (PA-15) y un router Cisco IOS, y explica qué debe coincidir en cada fase, cómo escribir los Proxy IDs en espejo con la ACL del Cisco y cómo diagnosticar los fallos más comunes (propuestas distintas, Proxy IDs que no coinciden, NAT-T). Antes de empezar, conviene haber leído IPsec Fundamentals y Site-to-Site VPN Estático.

Requisitos previos

• Haber leído IPsec Fundamentals y Site-to-Site VPN Estático
• Conectividad entre la IP pública del Palo Alto (por ejemplo 23.1.2.15) y la del Cisco (por ejemplo 24.1.2.20)
• Redes internas distintas: Palo Alto 10.10.0.0/24 y Cisco 192.168.20.0/24 (ejemplo)
• Acordar con el administrador del Cisco: versión de IKE (IKEv1 suele ser lo más compatible con crypto maps; IKEv2 también existe), cifrado, hash, grupo DH, PSK, lifetimes y las redes protegidas
• Acceso de administración al Cisco para configurarlo
• Reglas del firewall del Palo Alto para ike e ipsec, y NAT exemption (ver Source NAT)

Qué debe coincidir

Parámetro	Palo Alto	Cisco IOS (ejemplo)
Versión IKE	IKEv1 o IKEv2 en el IKE Gateway	crypto isakmp (IKEv1) o crypto ikev2
Cifrado Fase 1	IKE Crypto Profile: aes-256-cbc	encryption aes 256
Hash Fase 1	sha256	hash sha256
Grupo DH Fase 1	group14	group 14
Autenticación	Pre-Shared Key	authentication pre-share + crypto isakmp key
Cifrado y hash Fase 2	IPsec Crypto Profile: ESP aes-256-cbc / sha256	transform-set esp-aes 256 esp-sha256-hmac
PFS	group14 o no-pfs	set pfs group14 o sin esa línea
Redes protegidas	Proxy ID (local y remoto)	ACL del crypto map (en espejo)
Lifetimes	Pueden diferir; se usa el menor	lifetime

graph LR
    LANPA["LAN PA<br/>10.10.0.0/24"] --- PA["Palo Alto PA-15<br/>(basado en rutas)<br/>Proxy ID: 10.10.0.0/24 - 192.168.20.0/24"]
    PA == "IPsec" === CS["Router Cisco<br/>(basado en políticas)<br/>ACL: 192.168.20.0/24 - 10.10.0.0/24"]
    CS --- LANC["LAN Cisco<br/>192.168.20.0/24"]

Proxy ID y ACL deben ser espejo exacto

Si en el Palo Alto el Proxy ID dice Local 10.10.0.0/24, Remote 192.168.20.0/24, la ACL del Cisco debe decir origen 192.168.20.0/24 y destino 10.10.0.0/24 (y viceversa). Una diferencia de máscara o de red es la causa más común de que la Fase 2 no suba.

Configuración (Ejemplo)

1. Palo Alto: base

Sigue los pasos 1 a 6 de Site-to-Site VPN Estático (zona vpn, Tunnel Interface, IKE Crypto Profile, IPsec Crypto Profile, IKE Gateway, IPsec Tunnel, ruta) con estos ajustes:

1. IKE Gateway: Version IKEv1 only mode (si el Cisco usa IKEv1), Peer Address 24.1.2.20, Authentication Pre-Shared Key.
2. Advanced Options del IKE Gateway: Exchange Mode main (el predeterminado de Cisco; auto también funciona) y el IKE Crypto Profile acordado.
3. Ruta: Destination 192.168.20.0/24, Interface tunnel.1, Next Hop None.

2. Palo Alto: Proxy IDs

1. Network > IPSec Tunnels > Tunnel-to-Cisco > pestaña Proxy IDs > Add (IPv4).
2. Proxy ID Cisco-LAN, Local 10.10.0.0/24, Remote 192.168.20.0/24, Protocol Any.
3. Si el Cisco protege varias redes (varias líneas en la ACL), crea un Proxy ID por cada par.
4. OK y Commit.

set network tunnel ipsec Tunnel-to-Cisco auto-key proxy-id Cisco-LAN local 10.10.0.0/24 remote 192.168.20.0/24 protocol any

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

3. Palo Alto: NAT y políticas

1. Regla de NAT no-nat-vpn (Source Translation None) de inside a vpn entre 10.10.0.0/24 y 192.168.20.0/24, arriba de la regla de Internet.
2. Security Policy inside a vpn y vpn a inside para esas redes, y ike/ipsec desde y hacia el Cisco en outside.

4. Cisco IOS (ejemplo, IKEv1 con crypto map)

Los comandos exactos dependen del modelo y de la versión; este es un esquema típico:

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
!
crypto isakmp key <PSK> address 23.1.2.15
!
crypto ipsec transform-set TS-PA esp-aes 256 esp-sha256-hmac
 mode tunnel
!
ip access-list extended VPN-TO-PA
 permit ip 192.168.20.0 0.0.0.255 10.10.0.0 0.0.0.255
!
crypto map CMAP 10 ipsec-isakmp
 set peer 23.1.2.15
 set transform-set TS-PA
 set pfs group14
 match address VPN-TO-PA
!
interface GigabitEthernet0/0
 crypto map CMAP
!
! Excluir el tráfico VPN del NAT del Cisco (si aplica), con la ACL de NAT:
ip access-list extended NAT-ACL
 deny   ip 192.168.20.0 0.0.0.255 10.10.0.0 0.0.0.255
 permit ip 192.168.20.0 0.0.0.255 any

Si usas set pfs group14 en el Cisco, el IPsec Crypto Profile del Palo Alto debe tener DH Group group14; si el Cisco no la tiene, usa no-pfs.

5. Iniciar y probar

1. Genera tráfico desde la LAN del Cisco o del Palo Alto (el Cisco basado en políticas normalmente inicia el túnel al ver tráfico interesante).
2. En el Palo Alto: test vpn ike-sa gateway GW-Cisco y test vpn ipsec-sa tunnel Tunnel-to-Cisco.
3. En el Cisco: show crypto isakmp sa y show crypto ipsec sa.
4. Ping de host a host entre las dos LAN.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Network > IPSec Tunnels (Palo Alto)	Phase 1 y Tunnel Info en verde	Phase 1 rojo: PSK, IKE, propuestas; Tunnel Info rojo: Proxy ID/PFS/propuesta
show vpn ike-sa (Palo Alto)	IKE SA con el peer Cisco	Si no, less mp-log ikemgr.log
show vpn ipsec-sa (Palo Alto)	IPsec SA con el Proxy ID correcto	Si no, revisa Proxy IDs y PFS
show crypto isakmp sa (Cisco)	Estado QM_IDLE	Si dice MM_NO_STATE o similar, falla la Fase 1
show crypto ipsec sa (Cisco)	#pkts encaps y #pkts decaps subiendo	Si solo sube encaps, no regresa tráfico: revisa rutas y reglas en el Palo Alto
show vpn flow (Palo Alto)	Contadores encap/decap	Si falta un sentido, revisa ruta y NAT
less mp-log ikemgr.log (Palo Alto)	Mensajes “no proposal chosen”, “Proxy ID mismatch”	Indican exactamente qué diverge
Ping LAN a LAN	Respuestas	Si falla, revisa NAT exemption en ambos extremos
Monitor > Logs > System (subtype eq vpn)	Eventos de la negociación	Útil para ver el motivo

Errores comunes

La Fase 1 no sube

• Causa: versión de IKE distinta (IKEv1 frente a IKEv2), PSK diferente, propuestas incompatibles (cifrado, hash, DH), o el Cisco no tiene configurada la IP del peer.
• Revisa: less mp-log ikemgr.log y debug crypto isakmp en el Cisco (con precaución).
• Solución: alinea la versión y los parámetros; confirma la PSK y la dirección del peer en ambos.

La Fase 1 sube pero la Fase 2 falla con “Proxy ID mismatch” o “no proposal chosen”

• Causa: los Proxy IDs del Palo Alto no son espejo de la ACL del Cisco, o el PFS/transform-set difiere.
• Revisa: Proxy IDs, la ACL del Cisco (máscaras wildcard) y el transform-set.
• Solución: iguala redes y máscaras en ambos lados; confirma PFS y algoritmos.

Solo sube el túnel cuando el Cisco inicia

• Causa: el Cisco basado en políticas inicia con tráfico interesante; el Palo Alto no tiene tráfico que lo haga subir o tiene Passive Mode.
• Solución: genera tráfico desde ambos lados o usa test vpn en el Palo Alto; revisa Passive Mode del IKE Gateway.

El túnel sube pero no pasa tráfico

• Causa: falta la ruta por tunnel.1, no hay regla de Security Policy, o hay NAT en alguno de los lados.
• Solución: crea ruta y reglas; excluye el tráfico VPN del NAT en el Cisco y en el Palo Alto.

Varias redes en el Cisco y solo una funciona

• Causa: falta un Proxy ID por cada par de redes.
• Solución: crea un Proxy ID por cada línea de la ACL del Cisco (o usa redes agregadas iguales en ambos).

Hay NAT entre los dos extremos

• Causa: los peers ven IP distintas a las configuradas.
• Solución: activa NAT Traversal en ambos, y configura Local/Peer Identification explícitos.

El túnel se cae al renegociar

• Causa: lifetimes o PFS distintos hacen fallar la renegociación de Fase 2.
• Solución: alinea los lifetimes y el PFS.