Muchos de vuestros clientes cuentan con distintas oficinas en ubicaciones geográficamente distantes, y seguro que con la necesidad de comunicarlas para poder ofrecer los mismos servicios que en las oficinas centrales. Ahora llega la pregunta del millón, cómo conectar las distintas oficinas? Todos los ISP nos ofrecen múltiples tecnologías para ello:

Estas tecnologías son las que suelen manejar los ISP cuando queremos disponer de conectividad entre distintas ubicaciones, además nos permite contratar distintos servicios de alto valor añadido:

• Redundancia
• QoS
• Ancho de Banda
• Monitorización
• Seguridad

Pero por supuesto esto tiene un coste que no todas las empresas pueden asumir, a pesar de que ahora mismo tiene un coste más que razonable. De ahí que tengamos la necesidad de buscar alternativas, que a pesar de no tener estos servicios de valor añadido. También es cierto que no en todas las ocasiones necesitamos todas las funcionalidades de este tipo de enlaces, y únicamente buscamos conectar las distintas sedes del cliente. Pero claro, aquí no se nos puede pasar por alto lo más importante cuando utilizamos la WAN (insegura por defecto) para conectar distintas oficinas, que es ofrecer una capa de seguridad importante para que nadie libremente pueda interceptarlas, analizarlas y/o ser capaz de modificarlas. También es cierto que siempre debemos alinear las necesidades de seguridad con el coste que ello supone, pero hoy en día cualquier hardware que se precie soporta ciertos protocolos de seguridad. Existen múltiples tipos de VPN, esto es algo que debemos tener en cuenta en función del diseño que hagamos de la solución. Lo más común y sencillo de implementar es una VPN con IPSec Site-to-Site, para ello debemos tener dispositivos que soporten IPSec (es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos) y sobre él realizar las configuraciones necesarias. Yo os voy a mostrar como configurar un VPN con IPSec Site-to-Site con hardware Cisco, en este caso entre dos routers Cisco de la serie 1800. Este sería el esquema sobre el que se fundamentará la configuración de IPSec:

Esquema: Empresa con dos delegaciones que tiene los servidores principales en la sede central y una replicación de ficheros vía DFS

Como esta configuración "tipo" ya os la había comentado en su momento en otro artículo (La Nube Privada: Migración de Oficina, Beneficios del CPD y la VoIP) , me voy a centrar en configurar la autenticación de la Fase 1 utilizando certificados digitales emitidos por nuestra CA. Para refrescarnos la memoria, aquí os dejo la configuración que había utilizado en este artículo de la Nube Privada …. pero cambiando la autenticación de Preshared Key a RSA-SIG, aportando un plus de seguridad y escalabilidad:

Ahora debemos configurar nuestra CA para que los dispositivos de red puedes solicitar su certificado, para ello vamos a utilizar el Servicio de Inscripción de Dispositivos de Red de nuestra CA en Windows Server. Yo utilizaré Windows Server 2012, y lo primero que debemos hacer es configurar primero nuestra CA: Windows Server 2012, Instalación de una CA. Y durante la instalación o a posteriori configuraremos el Servicio de Inscripción de Dispositivos de Red, yo ya tengo la CA instalada y vamos a ver como podemos configurar el servicio de Servicio de Inscripción de Dispositivos de Red. Para ello vamos a la consola de Administración de nuestro servidor, vamos a Administrar – Agregar Roles y Características y seguimos el asistente hasta que se complete la instalación:

Ahora debemos seleccionar Servicio de inscripción de dispositivos de red y pulsamo en Siguiente

Pulsamos en Siguiente

Una vez que se ha completado la instalación debemos pulsar en Configurar Servicios de certificados de Active Directory en el servidor de destino
Por defecto el usuario que instalará que configurará los servicios del ROL será el usuario con el que hayáis iniciado sesión, ya doy por hecho que sois miembros del grupo Admins. del Dominio. Pero en todo caso si queréis elegir otro usuario para realizar la  configuración de este servicio

Debemos seleccionar un usuario que se usará para el servicio de inscripción de certificados, como véis nos avisa de que debe ser miembro del grupo IIS_IUSRS local, pulsamos en seleccionar

Introducimos el nombre del usuario del dominio (debe ser miembro únicamente del grupo de Usuarios del Dominio) e introducimos sus credenciales

pulsamos en Siguiente

Cubrimos los datos de nuestra organización y pulsamos en Siguiente

Podemos dejarlo por defecto y pulsamos en Siguiente

Por último nos muestra un resumen de la configuración y pulsamos en Configurar

Ahora que hemos finalizado veremos que los certificados que tenemos disponibles para la inscripción desde los dispositivos de red serán de la plantila de IPSecCIntermediateOffline. Si quisieramos utilizar una plantilla de certificado personalizada, tendríamos que crear nueva plantilla y editar el registro para cambiar el nombre del certificado a emitir: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP: EncryptionTemplate, GeneralPurposeTemplate, SignatureTemplate y luego reiniciar el IIS para que los cambios se hayan aplicado correctamente.

Ahora vamos a revisar que el usuario asignado para el servicio de inscripción de certificados para dispositivos de red tiene acceso de inscripción de esta plantilla, para ello vamos a la consola de la entidad certificadora, vamos a Plantillas de Certificado y pulsamos con el botón secundario del ratón y pulsamos en Administrar

Debemos ir a las propiedades de la plantilla de  IPSECIntermediateOffline y vamos a la pestaña de seguridad para poder verificar que el usuarios NDES (es el usuario comentario anteriormente) tiene acceso de inscripción sobre esta plantilla

Una vez revisado los permisos básicos y que en nuestro caso la plantilla de certificado que necesitamos es esta, ahora debemos acceder a la URL de administración de emisión de certificados para dispositivos de red. Para ello debemos escribir la siguiente URL: http(s)://fqdn_servidor/certsrv/mscep_admin, ahora os solicitará las credenciales de acceso y debéis iniciar sesión con  un usuario que tenga acceso de inscripción de certificados para las plantillas de IPSECIntermediateOffline, en caso contrario os dará acceso denegado. 

Si cuando accedemos a la URL comentada nos encontramos con este error
debemos revisar el méto de inicio de sesión, que por defecto es negotiate pero si no tenemos los registros SPN actualizados no nos permitirá autenticar. En mi caso como no utlizo el FQDN del sevidor sino un registro CNAME para darle otra URL al acceso web de inscripción de certificados y no tener el SPN creado, no me permitirá autenticarme por Kerberos por lo que tengo que modificarlo de Negotiate a NTLM. Si bien es cierto que puedo crear el SPN adecuado y demás, pero por agilizar la guía no lo he hecho cambiando solo lo he modificado el orden de los proveedores habilitados y  he puesto NTLM el primero en la lista

Ahora he vuelto a acceder a la URL comentada anteriormente y me muestra el siguiente error
Para solucionar este problema he utilizado est KB de MSFT: http://support.microsoft.com/kb/2800975 y debéis seguir estos pasos para solucionarlo

1) Install and configure NDES (and CEP/CES).
2) Open IIS.
3) Select “Default Web Site”. 
4) Click “View Applications” in the action panel on the right.
5) Double click the mscep application.
6) Double click “Handler Mappings”.
7) Click “View Ordered List…” in the action panel.
8) Select ExtensionlessUrlHandler-ISAPI-4.0_64bit and move it down so it is below StaticFile.
9) Repeat steps 6-8 for the mscep_admin application.
10) Restart IIS.

Aquí so muestro los pasos en imágenes

Nota: Esto me ha pasado en casi todas las implementaciones de NDES con Windows Server 2012

Ahora volvemos a tratar de acceder a la URL de NDES y ya podemos acceder correctamente, como vemos nos ofrece la huella digital del certificado a emitir y su clave de solicitud, que como podéis obsevar tendrá una validez de 60 min y solo se puede usar una vez. Este comportamiento se puede modificar editando el registro, pero yo prefiero que dejarlo así. Se puede quitar la solicitud de contraseña, etc.. pero mejor dejémoslo así.

Nota a tener en cuenta de MSFT

• Espere hasta que una de las contraseñas haya expirado antes de enviar una solicitud nueva.
• Detenga y reinicie Internet Information Services (IIS) para eliminar todas las contraseñas almacenadas en la memoria caché.
• Configure el servicio para que almacene en la memoria caché más de cinco contraseñas.

Ya tenemos todo preparado para que nuestros dos routers Cisco puedan solicitar su certificado, para ello debemos seguir los siguientes pasos:

1º Crear los RSA necesarios: crypto key generate rsa general-keys label <Etiqueta> modulus 2048

2º (Opcional) Configurar un servidor DNS para que el router pueda resolver nombres de dominio: ip name-server <dirección_IP>. Esto nos ayudará a resolver el nombre de la URL del NDES, y no tenemos que estar utilizando la dirección IP.

3º Configuramos las opciones de inscripción del certificado por parte del router

crypto pki trustpoint EQ2B
 enrollment mode ra
 enrollment url http://ca.eq2b.com:80/certsrv/mscep/mscep.dll
 usage ike
 serial-number
 revocation-check none
 rsakeypair EQ2BRSA
 auto-enroll

4º Enviaremos la solictud de autenticación a la CA: crypto pki authenticate <nombre_trustpoint>

Como vemos en la URL del NDES MD5 la huella digital que nos está mostrando en la misma que nos devuelve en el router

5º Enviaremos la solicitud de inscripción del certificado a la CA: crypto pki enroll <nombre_trustpoint>. Como vemos nos solicita una clave para poder solicitar el certificado, la clave es la que nos muestra en la página en la URL de NDES

Ahora si queremos ver el certificado  recibido escribiremos: sh crypto ca certificates EQ2B

Ahora ya tenemos nuestro certifcado en el router, y si nos vamos a la consola de la CA a Certificados Emitidos y vemos que se ha emitido el certificado en base a la plantilla IPSEC (solicitud sin conexión) y el nombre del solicitante es el usuario NDES. Este usuario es el que previamente habíamos configurado con el asistente inicial

6º Ahora debemos cambiar el modo de autenticación de nuestra configuración de IPSec en la Fase 1: authentication rsa-sig
 crypto isakmp policy 10 

  authentication rsa-sig

Si ahora escribimos el siguiente comando nos mostrará un resumen de como ha quedado configurado nuestra Policy: sh crypto isakmp policy

Esto es todo lo que debemos hacer en cada uno de los routers que, así que debemos repetir los seis pasos en el otro router del otro extremo de la VPN. Una vez completados si vamos a la consola de administración de la CA vemos que ya aparecen los dos certificados emitidos.

Una vez que ambos routers están configurados con sus correspondientes certificados, y que se ha cambiado la configuración de Preshared key a RSA-SIG  los routers volverán a negociar IPSec y tratar de conectarse. Aquí os muestro parte de un log de la negociación de IPSec entre ambos routers:

Si queremos verificar que se ha establecido la VPN correctamente, escribimos el siguiente comando en el router: sh crypto isakmp sa y como vemos está en estado QM_IDLE por lo que estamos conectados