Configuracion VPN Checkpoint

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.