Configuracion VPN checkpoint Tue, 09/29/2009 - 12:11 by sysadmin Tags:
Firewalls
Un clasico, mil veces que lo configuras y siempre metes la pata en algo. El sistema no ha cambiado mucho a lo largo del tiempo asi que, ahi van los pantallazos. Primero definimos el servidor de túneles remoto (Interoperable Device) desde Network Objetcs -> New-> Other>Interoperable Device.
Damos ok, y volvemos a seleccionar el objeto. Pinchamos sobre VPN y añadimos myintranet En topoliga tenemos que añadirle el objeto network (que tenemos que haber definido previamente). Esta red es la que vamos a alcanzar detras de la VPN (la remota). VPN Advanced, seleccionamos custom settings y one VPN tunnel per each pair of hosts. Link selecction por si quieres poner el extremo del tunel en otra ip, en mi caso, me vale con main address. Ahora vamos a VPN communities -> Site to Site -> Myintranet, debemos ver el interoperable object que hemos definido anteriormente-> le damos add y añadimos el objeto de nuestro firewall. Despues definimos las propiedades de la
VPN. En mi caso lo pusimos con 3DES y MD5 para las dos fases. Vamos a Tunnel Management y seleccionamos el tunel como permanente (en caso de que lo necesites, claro).
Advanced Settings, shared secret, marcamos Use only shared secret for all external members y ponemos la correspondiente key al objeto Advanced VPN Properties. Ajustamos el intercambio de claves y deshabilitamos el NAT dentro de la VPN (si es lo que necesitas, en mi caso lo pasamos por routing). Siguiente paso, definimos los objetos siguientes: - Redes que tienen que tener acceso a la VPN - EL grupo que las contiene Despues seleccionamos el objeto firewall (el nuestro)-> topology ->seleccionamos el dominio VPN a manual y añadimos el grupo con las redes que hemos creado antes. Vamos a VPN y seleccionamos myintranet como VPN community. Despues VPN advanced y le ponemos los mismos parametros que al Interoperable device Con estos pasos ya tenemos definido el tunel. Antes de compilar la pólitica hayq ue crear las reglas correspondientes para permitir el trafico entre los hosts de ambas redes (lo normal, vamos). Compilamos y comprobamos si se establece el tunel, si todo va bien deberiamos ver en el log el establecimiento del mismo y el trafico pasando al otro extremo.
VPN site to site en Checkpoint con NAT Esta semana hemos tenido que ayudar con una VPN site to site entre un Checkpoint y un Cisco ASA. Ha sido interesante ya que la forma en que Checkpoint configura las VPN site to site, es ligeramente distinta de la mayoría de los firewalls. En checkpoint el dominio de encriptación (o las redes internas entre las que se establecen los túneles) de fase 2 se define a través de algo llamado communities que codicionan la selección de los paquetes que se envían a través del túnel, como veremos más adelante.
El esquema del caso es: Se ha de establecer el tunel entre las redes LAN A y LAN B con el problema añadido de que la red 192.168.1.0/24 se encuentra en uso en la red del Peer B ya que es parte de la LAN C a la cual se accede desde LAN B a través del Checkpoint. Para solucionar el tema de solapamiento entre la LAN A y la LAN C se establece un NAT en Checkpoint enmascarando la LAN A con la red 192.168.3.0/24 que no se encuentra en uso en la red del Peer B. La configuración del tunel en el Checkpoint quedó establecida así: Configuracion del tunel: Community: PeerA-B. Nodos:
1) Nodo Peer A: - IP Pública: 80.27.22.11 - Dominio de encriptación: 192.168.1.0/24 1) Nodo Peer B: - IP Pública: 90.27.22.22 - Dominio de encriptación: 192.168.2.0/24 Regla de Acceso LAN A
LAN A
NATEO LAN A —> NATEO LAN A —> Todos los servicios —> Aceptar LAN B
LAN B
Configuración de NAT IPorig
IPdst
192.168.1.0/24
any
any
192.168.3.0/24
TraduccOrig 192.168.3.0/24 =
TraduccionDst = 192.168.1.0/24
Con esta configuración, el tunel levanta si la comunicación es iniciada por el Peer A y los paquetes pasan encriptados a través del tunel tanto para el tráfico desde A a B como desde B a A. El problema es que si la comunicación es iniciada por B, el túnel no levanta y los paquetes son enviados hacia la LAN C, tal y como indica la tabla de rutas de Checkpoint.
Al mirar los logs en tracker pordíamos observar entradas que aceptaban el tráfico entre los dos extremos del tunel: 192.168.2.x —> 192.168.3.y —> UDP_200 —> ACCEPT También podíamos observar en estos logs que el NAT se estaba realizando correctamente por lo que la comunicación, con la traduccion de direcciones quedaba: 192.168.2.x —> 192.168.3.y (Xlatedst: 192.168.1.y) —> UDP_200 —> ACCEPT Al mirar los logs de la pestaña VPN, no aparecía ninguna entrada perteneciente al tunel, lo que indica que no trata de levantar el túnel porque no considera este tráfico VPN. Se inició la comunicación desde el Peer A para que el túnel mantuviese levantada la fase 1 y se realizaron pruebas de acceso desde el Peer B (iniciando este la comunicación) hacia el Peer A. En los logs de VPN apareció una entrada como: Number:
718105
Date:
4Mar2010
Time:
18:08:05
Product:
VPN-1 Power/UTM
VPN Feature:
IKE
Interface:
daemon
Origin:
CHECKPOINT
Type:
Log
Action:
Key Install
Source:
CISCO_ASA
Destination:
CHECKPOINT
Encryption Scheme:
IKE
VPN Peer Gateway:
CISCO_ASA
IKE Phase2 Message ID:
14b7d641
Community:
Peer A-B
Subproduct:
VPN
Information:
IKE: Quick Mode Received Notification from Peer: invalid id
information El mensaje “Invalid id Information” en el establecimiento de la fase 2 indica que existe algún error en las redes configuradas en el dominio de encriptación ya que no coinciden con los datos de los que dispone el peer remoto. Este mensaje fue la pista definitiva para dar con la solución. Había algo incorrecto en el dominio de encriptación remoto. Para que funcionen las VPNs de Checkpoint con NAT, hay que incluir la red del NAT en objeto que representa al PeerA en la comunity que define la VPN en checkpoint. 1) Nodo Peer A: - IP Pública: 80.27.22.11 - Dominio de encriptación: 192.168.1.0/24; 192.168.3.0/24. Al instalar políticas con este cambio, el checkpoint considera los accesos 192.168.2.x —> 192.168.3.y (Xlatedst: 192.168.1.y) —> UDP_200 —> ACCEPT como accesos de VPN y hace que los paquetes vayan por el túnel estableciendose correctamente la comunicación. Ahora aparecen entradas en la pestaña VPN del tracker que indica que el tráfico está pasando por él. Espero que este post sea de utilidad a alguien. Más adelante escribiré algún post con el procedimiento general para configurar una VPN con Checkpoint.
