En este laboratorio, os mostraremos como establecer túneles IPSEC en Check Point, donde los peers remotos no pueden tener una dirección IP pública estática. Esto en otros fabricantes está bastante documentado (una DMVPN) y hay mucha información, pero en Check Point quizás no haya tanta o sea un poco confusa.
Check Point afronta esto usando la autenticación basada en certificados, para hacer la POC he usado un Check Point con IP pública estática (obviamente 😊) y el peer remoto ha sido un Palo Alto con IP pública dinámica.
Nos da igual la IP realmente, ya que no tenemos que configurarla en ningún sitio.
VPN Certificate Bases Authentication
El objeto de esta configuración es que los peers remotos no necesiten una IP pública estática para poder establecer el túnel IPSEC. Además de que la configuración por certificados es más segura y recomendada (aunque un poco más compleja de implementar).
Para ello, se ha montado un laboratorio, donde el peer remoto es un firewall Palo Alto.
Documentación usada Check Point:
Para esta topología de autenticación por certificados, se va necesitar una CA que firme certificados.
He creado una manualmente y las he añadido como CA de confianza en ambos sistemas, Check Point y peers, mediante este script:
CANAME=Prueba-RootCA
# optional, create a directory
mkdir $CANAME
cd $CANAME
# generate aes encrypted private key
openssl genrsa -aes256 -out $CANAME.key 4096
# create certificate, 1826 days = 5 years
# the following will ask for common name, country, ...
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 3600 -out $CANAME.crt
# ... or you provide common name, country etc. via:
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 3600 -out $CANAME.crt -subj '/CN=MyOrg Root CA/C=AT/ST=Laboratorio/L=Lab/O=MyLab'
MYCERT=PruebaDMVPN
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj '/CN=My Firewall/C=AT/ST=Laboratorio/L=Lab/O=MyLab'
# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = myserver.local
DNS.2 = myserver1.local
IP.1 = 192.168.1.1
IP.2 = 192.168.2.1
EOF
openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 3600 -sha256 -extfile $MYCERT.v3.ext
Para facilitar el escenario, el certificado que presenta el Check Point al peer también se ha generado con la misma CA que se generó el del peer. En este caso Prueba-RootCA.
Para ver la siguiente vista es necesario realizar la configuración que se detalla más adelante en la configuración del Check Point
Configuración Check Point VPN
Lo primero que tenemos que hacer es habilitar el blade IPSEC en el Gateway.
Los peer remotos (equipos que no son Check Point) se deben definir como Interoperable Device. Es importante marcar la opción que la IP del peer será dinámica.
Será obligatorio definir manualmente al menos una interfaz en el apartado de topología
Debe de definirse que CA será la que valide el certificado del peer remoto así como el DN que debe hacer match el certificado que presente el peer.
Hay que importar la CA que emita el certificado del peer:
En este caso, como vamos a tener más de un peer remoto, vamos a montar una comunidad en estrella. Donde el Check Point será el Gateway central y el resto de peers serán los satélites
El dominio de encriptación ( Redes internas entre las que se establecen los túneles ) en el túnel será el siguiente
- Checkpoint -> Direcciones IP de MGMT
- Peer Remoto (Palo Alto) -> 192.168.200.0/24 (Una red LAN cualquiera)
Cambiamos los parámetros de encriptación a unos más robustos:
Una vez definido esto solo faltaría permitir por políticas el tráfico dentro de la comunidad:
¿Cómo comprobar que se ha establecido correctamente el túnel VPN? En los logs de Check Point filtramos por action:"key install"
Veremos como en el campo USER aparece el certificado que está presentado en peer remoto, que si comprobamos, hace match con lo que definimos en el "Interoperable Device"
Con ello, se comprueba que hay tráfico en la comunidad:
NOTA: En esta topología peer remoto (Palo Alto) y Check Point con autenticación basada en certificados y comunidad en estrella, se ha tenido que deshabilitar la aceleración de tráfico VPN para el peer remoto. Como podemos ver aquí
Configuración Peer Remoto (en este caso Palo Alto)
El dispositivo que se ha usado para la simulación del peer, es un Palo Alto virtualizado usando GNS3 (en su interfaz externa se obtiene el direccionamiento por dhcp ) y la topología que se ha montado es la siguiente:
La idea es que desde la ZONA LAN se pueda acceder a la gestión de los Check Point . Al estar en una red privada, es el router interno de mi casa quien hace el NAT de salida a INET.
Se han usado los siguientes recursos para montar el LAB:
La configuración en PA realmente no es objeto de esta POC, pero se detalla lo más significativo.
- Es necesario que tanto las Fases 1 y 2 de IPSEC estén configuradas exactamente igual en ambos extremos.
- El dominio de cifrado o IP que vayan a cursar tráfico en el túnel deben ser exactamente igual en ambos extremos.
- Hay que poner ruta estática para redirigir el tráfico que deba ir por el túnel.
- Los túneles solo se levantarán bajo demanda.
Configuración de autenticación con certificados:
Perfil de certificados usado, que contiene las CA involucradas en la autenticación:
Espero que os sirva.
