Configurar túnel site to site FlexVPN con IP dinámica (DHCP) con routers Cisco

Configurar túnel site to site FlexVPN con IP dinámica (DHCP) con routers Cisco

Esta configuración es muy sencilla cuando se encajan todas las piezas. Se debe utilizar FlexVPN en modo cliente/servidor, se puede elegir diferentes modos de autenticación: certificado, radius, tacacs+…En este artículo se utilizará la más sencilla, usuario y contraseñas locales.

Se utilizará un laboratorio ejecutado en el fantástico eve-ng :). El laboratorio utilizado es el siguiente:

Configuración del servidor

Puedes descargar la configuarción completa del servior en este enlace. A partir de aquí nos centraremos en las secciones relevantes para el fín del artículo.

Reglas de acceso

Empezaremos por las ACL y el pool utilizado para asignar direcciones a los clientes VPN:

ip local pool FlexVPNPool 10.10.10.1 10.10.10.254 recycle delay 60
!
ip access-list standard ServerNetwork
permit 10.0.0.0 0.0.0.255
!
ip access-list extended Client1-ACL
permit icmp host 10.0.0.3 192.168.1.0 0.0.0.255 echo
permit icmp host 192.168.1.0 0.0.0.252 10.0.0.3 echo-reply
permit tcp host 10.0.0.3 192.168.1.0 0.0.0.255 eq 22
deny ip any any
ip access-list extended Client2-ACL
permit icmp host 10.0.0.3 192.168.2.0 0.0.0.255 echo
permit icmp host 192.168.2.0 0.0.0.252 10.0.0.3 echo-reply
permit tcp host 10.0.0.3 192.168.2.0 0.0.0.255 eq 22
deny ip any any

Se ha elegido segmentar las reglas de acceso de cada cliente, pero se podría utilizar una genérica para todos. Hemos elegido esta arquitectura, que se replicará en otros elementos, para evitar que errores de configuración de un nuevo túnel, pueda afectar a túneles ya configurados. Se utiliza un único pool «FlexVPNPool» para todos los clientes, se podría usar uno para cada cliente, si se desea.

En cuanto a la red protegida por el servidor, se define mediante la ACL ServerNetwork, las ACL Client1-ACL y Client2-ACL se utilizan para limitar el tráfico permitido en cada túnel. En caso de haber un firewall entre la red servidor y las redes clientes, no hará falta definir estas reglas.

Política de autorización

A continuación se define la política de autorización utilizada, para este elemento también se ha escogido utiliizar uno compartido, pero se podría usar uno por túnel:

crypto ikev2 authorization policy FlexVPNIKEPOL
pool FlexVPNPool
route set access-list ServerNetwork

Mediante esta autorización se selecciona el pool a utilizar, es por utilizar un único bloque de autorización que se utiliza una pool compartida. Aquí también se específica el tráfico que será enrutada en el otro extremo, las rutas a inyectar en el cliente, en este caso la red de servidores.

Claves de conexión PSK (preshared keys)

Es el momento de definir las contraseñas de acceso para cada cliente, para ello se utiliza un anillo de claves, que las almacena:

crypto ikev2 keyring KR
 peer client1
  identity fqdn client1.domain.com
  pre-shared-key local ServerToClient1Key
  pre-shared-key remote Client1Key
 !
 peer client2
  identity fqdn client2.domain.com
  pre-shared-key local ServerToClient2Key
  pre-shared-key remote Client2Key

Cada cliente se identificará mediante FQDN, es importante remarcar que en ningún caso se realiza resolución de nombres, tan solo se utilizan como elemento identificativo. Por lo tanto se puede utilizar cualquier combinación, sin necesidad de que cumpla con ningún estándar ni de que exista en ningún servidor DNS. Se puede definir una clave única para local y remoto, si se desea. En este elemento sí

Perfiles ikev2

Ahora se definen los perfiles para cada cliente, en estos bloques también se utiliza el FQDN para identificar a los clientes:

crypto ikev2 profile ikev2-profile
 match identity remote fqdn client1.domain.com
 authentication local pre-share
 authentication remote pre-share
 keyring local KR
 aaa authorization group psk list default FlexVPNIKEPOL
 virtual-template 1
!
crypto ikev2 profile ikev2-profile-client2
 match identity remote fqdn client2.domain.com
 authentication local pre-share
 authentication remote pre-share
 keyring local KR
 aaa authorization group psk list default FlexVPNIKEPOL
 virtual-template 2

Se ha elegido separar los bloques por cliente, pero se podría definir un bloque único utilizando el dominio del FQDN como elemento identificativo, especificando del match de la siguiente manera:

match identity remote fqdn domain domain.com

Parámetros para IPSEC

A continuación se define la configuración para IPSEC, mediante un único transform-set y un perfil por cliente:

crypto ipsec transform-set transform1 esp-aes
 mode tunnel
!
!
crypto ipsec profile ipsec-profile
 set transform-set transform1
 set ikev2-profile ikev2-profile
!
crypto ipsec profile ipsec-profile-client2
 set transform-set transform1
 set ikev2-profile ikev2-profile-client2

El perfil IPSEC enlaza el cifrado para IPSEC con el utilizado en la fase de intercambio de claves ikev2. Es decir específica qué cifrado se utilziará para la fas1 y la fase2 de la negoaciación.

Interfaces de red

Se finaliza mediante la configuración de las interfaces que intervendrán en el túnel:

interface Loopback0
 ip address 10.10.11.1 255.255.255.255
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip access-group Client1-ACL out
 tunnel mode ipsec ipv4
 tunnel destination dynamic
 tunnel protection ipsec profile ipsec-profile
!
interface Virtual-Template2 type tunnel
 ip unnumbered Loopback0
 ip access-group Client2-ACL out
 tunnel mode ipsec ipv4
 tunnel destination dynamic
 tunnel protection ipsec profile ipsec-profile-client2

La interfaz Loopback0 se utiliza como orígen para los túneles, es una buena práctica en cisco, ya que es una interfaz que siempre está activa y puede ser accesible desde cualquier interfaz mediante routing. Se suele utiizar como IP de gestión una Loopback, también como buena práctica. La IP de esta interfaz no interviene en el túnel y no tiene por qué coincidir con la pool o con cualquier otra IP del equipo.

Se utiliza un virtual-template para cada túnel, esto sirve para asociar al túnel las reglas de acceso de cada túnel «ip access-group…» y el perfil IPSEC de cada cliente «tunnel protection ipsec…«. En caso de no separar la configuración por cliente, bastaría con una única virtual-template.

Configuración de los clientes

Puedes descargar la configuarción completa de los clientes en el enlace a cliente 1 y en el enlace a cliente 2. A continuación se explican las partes más relevantes para el cliente1, el dos es igual modificando las direcciones IP que intervienen.

Política de autorización

Se define una política de autorización, que especifica las rutas que se inyectarán hacia el servidor:

crypto ikev2 authorization policy FlexVPNIKEPOL
 route set interface
 route set remote ipv4 192.168.1.0 255.255.255.0

La sentencia «route set interface» envía la direción del IP del túnel como ruta estática al otro extremo.

Claves de conexión PSK (preshared keys)

Se define un anillo de claves para la gestión de las contraseñas de conexión:

crypto ikev2 keyring KR
 peer SERVER1
  address 172.16.0.3
  pre-shared-key local Client1Key
  pre-shared-key remote ServerToClient1Key

Este paso no es obligatorio, las claves se pueden especificar en el perfil ikev2 directamente.

Perfiles ikev2

Igual que en el servidor se define un perfil ikev2:

crypto ikev2 profile prof
 match identity remote address 172.16.0.3 255.255.255.255
 identity local fqdn client1.domain.com
 authentication local pre-share
 authentication remote pre-share
 keyring local KR
 aaa authorization group psk list default FlexVPNIKEPOL

En este bloque hay que resaltar varios parámetros:

  • match identity remote address: indica la IP externa del otro extremo, normalmente será una IP pública, pero puede ser privada también, en función de las necesidades.
  • identity local fqdn: Este parámetro debe coincidir con el nombre que se utiliza en el servidor para identificar al cliente. En caso de que se disponga de una IP fija externa, se puede utilizar esa IP como elemento identificativo del cliente.
  • aaa authorization group psk list default: Esta sentencia tiene una doble función, por un lado especifica el nombre de grupo que se utilizará durante la fase de autenticación, debe coincidir con el indicado en el servidor. Por otro lado asocia la política de autorización a utilizar para el túnel.

Parámetros para IPSEC

Al igual que en el servidor o cualquier tipo de túnel IPSec, se deben configurar los parámetros para IPSec:

crypto ipsec transform-set trans esp-aes
 mode tunnel
!
!
crypto ipsec profile ipsecprof
 set transform-set trans
 set ikev2-profile prof

Se establecen los parámetros de cifrado y firma para el túnel en el transform-set y mediaten el perfil se enlazan los parámetros para la fase 1 (perfil ikev2) y la fase2 (transform-set).

Interfaces de red

A continuación se define la interfaz túnel a utilizar:

interface Tunnel0
 ip address negotiated
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination dynamic
 tunnel protection ipsec profile ipsecprof

La dirección IP será negociada, la proporciona el servidor, como interfaz orígen se utiliza la deseada G0/0 en este caso, podría ser una loopback o cualquier otra interfaz que enrute hacia el servidor.

Se indica que el tunel será de tipo ipsec en ipv4, mediante tunnel destination dynamic indica que se obtendrá de un listado (se configura en el siguiente paso) y se asocia el perfil IPSec a utilizar.

Habilitar flexvpn

En el cliente se debe indicar que se utilizará flexvpn para la conexión:

crypto ikev2 client flexvpn flex
  peer 1 172.16.0.3
  client connect Tunnel0

Se indica a qué extremo se va a conectar, permite indicar más de un extremo y si falla la conexión a uno sigue en orden por cada extremo definido. También indica qué interfaz túnel se va a utilizar para realizar la conexión. Es aquí donde es establecen los valores que utilizará la interfaz túnel para la sentencia «tunnel destination dynamic«

Abdul Pallarès

Deja tu mensaje

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.