Demostración Conectando Clientes a la Red por VPN – Windows Server 2008-R2 y Windows 7 – Parte 2 por L2TP-IPSec, SSTP y IKEv2

En esta segunda nota continuaremos con la configuración para conectar clientes a la red por VPN, completando los tres protocolos adicionales: L2TP+IPSec, SSTP y IKEv2.

Esta nota supone que está disponible y funcionando correctamente lo ya descripto en la primera parte Demostración Conectando Clientes a la Red por VPN – Windows Server 2008-R2 y Windows 7 – Parte 1 por PPTP

Además, considerando que para configurar los otros protocolos necesitamos una infraestructura que simula Internet, donde tendremos disponible el servicio DNS y una Autoridad Certificadora, antes de comenzar se deberán completar los procedimientos detallados en Preparación de simulación de Internet para Demostraciones

Recordemos lo que configuramos en la primera parte:

En la preparación de la simulación de Internet agregamos a la red marcada como Internet en la figura anterior, un servidor (inet-srv.isp.com) que tiene configurado:

• Servidor DNS, con la zona correspondiente a guillermod.com.ar (representativa de la presencia en Internet de la empresa), con el registro A correspondiente a vpn.guillermod.com.ar que apunta a la interfaz externa de VPN1
• Autoridad Certificadora de tipo Raíz llamada Comercial-CA

Dado que los protocolos que usan certificados necesitan resolución de nombres, debemos configurar en CL1 al servidor DNS que resolverá los nombres. En nuestro caso será 131.107.0.100 (inet-srv.isp.com)

De la nota anterior ya tenemos configurado el acceso por PPTP, en esta comenzaremos creando en el cliente tres conexiones más, usando cada uno de los tres protocolos restantes.

Comenzamos por crear la conexión que usará L2TP+IPSec

Para eso en el Network and Sharing Center, elegimos Setup a New Connection or Network, y seguimos el asistente usando como nombre un identificador del protocolo que usará, en este caso “Conexión L2TP+IPSec”

En las propiedades de la conexión específicamente marcamos que se usará L2TP+IPSec

Siguiendo el mismo procedimiento, crearemos dos conexiones más, pero especificando en una el protocolo SSTP, y en la otra IKEv2

Quedando finalmente la conexión de red local y las cuatro de VPN ya configuradas

Para que no tengamos dudas, que ninguna funcionará sin configuración adicional podemos probarlas

Visto lo anterior, podemos sacar la primera conclusión

CONCLUSIÓN 1: PPTP es la más fácil de implementar

Es fácil darnos cuenta que al usar protocolos que utilizan certificados, necesitaremos como primera medida obtener un certificado digital de máquina para el servidor VPN1

Como el asistente de configuración de VPN ha colocado filtros tanto de entrada como de salida en la interfaz externa, debemos momentáneamente permitir tráfico para poder acceder a solicitar e instalar el correspondiente certificado.
Para no hacer más compleja esta demostración, simplemente permitiré todo el tráfico tanto de entrada como de salida en la interfaz externa.

Para esto en VPN1, en Routing and Remote Access, vamos a las propiedades de esta interfaz, y agregamos permitir el tráfico a todos los protocolos. Las siguientes figuras muestran el procedimiento. Repetiremos el procedimiento tanto para Inbound Filters como para Outbound Filters.

Y por último reiniciamos el servicio para asegurarnos que tome la configuración

La última configuración preparatoria que haremos es agregar en la interfaz externa de VPN1 la dirección de nuestro servidor DNS de “Internet”

Los procesos que ejecutaremos a continuación, y que aparentemente complejizan esta demostración, están determinados por tres causas fundamentales:

1. Las mejoras de seguridad de Internet Explorer
2. El hecho de estar utilizando una Autoridad Certificadora propia, no comercial, que no forma parte del programa de Microsoft
3. Las mejoras de seguridad en el manejo de certificados digitales, que se instalarán por usuario, aunque sean certificados de máquina

Así que dispongámonos a “trabajar” :-)

En VPN1, en la configuración de seguridad de Internet Explorer, agregaremos a nuestra autoridad certificadora, como parte de nuestra Local Intranet, y debemos bajar el nivel predeterminado de seguridad al mínimo.

Siguiente nos conectaremos por HTTP al sitio web de la Autoridad Certificadora (en adelante la CA) para descargar el certificado de la CA, que dejaré sobre el Desktop

De esta misma página descargamos además la última Base CRL que dejaremos también sobre el Desktop (Agregarle la extensión de archivo CRL a mano)

A continuación, crearemos una consola (MMC) donde cargaremos los complementos Certificates para “My user” y “Local Computer”

Importamos el certificado de la CA en Trusted Root Certification Authorities de la parte de máquina

Con botón derecho sobre el archivo CRL que dejamos sobre el Desktop elegimos “Install CRL”

Está CRL quedará instalada en Certificates – Current User / Intermediate Certification Authorities / Certificate Revocation List.
Con Copiar/Pegar la agregaremos en el mismo lugar pero en la parte de Certificates (Local Computer)

Por último, solicitaremos el certificado de máquina

Atención con la pantalla que sigue. Debemos especificar el nombre que utilizará el cliente para acceder a la máquina, independientemente del nombre que tenga localmente, en este caso “vpn.guillermod.com.ar”
También prestar especial atención que se trata de un certificado para Server Authentication, y que debemos marcar que se pueda exportar la clave privada

Al estar usando una CA de tipo stand-alone, debemos ir a la consola de administración de la misma en la máquina inet-srv.isp.com y otorgar el certificado solicitado.

Ahora nuevamente desde VPN1, vemos el estado del pedido e instalaremos el certificado otorgado

Llegados a este punto, si deseamos podemos ir a Enrutamiento y Acceso Remoto y eliminar los filtros de seguridad que habíamos hecho provisoriamente para permitir el tráfico de obtención de certificados.
Lo mismo para restaurar la configuración por omisión de Internet Explorer.

Nos falta lo últimio. Como aunque es un certificado de máquina, el sistema lo ha instalado en la parte de usuario, debemos exportarlo de una parte para importarlo en la otra

Si volvemos a CL1 y volvemos a probar las cuatro conexiones que hicimos anteriormente podremos verificar que:

• PPTP: sigue conectándose sin problemas
• L2TP+IPSec: no se conecta, se requiere certificado de máquina en el cliente
• SSTP: sigue sin conectarse, ya que no puede verificar el certificado del servidor VPN
• IKEv2: sigue sin conectarse, ya que no puede verificar el certificado del servidor VPN

Ante esto es evidente lo que nos falta. Si estuviéramos utilizando una autoridad certificadora comercial adherida al programa de MIcrosoft ya tendríamos resuelta la conectividad por SSTP y IKEv2.

Como estamos en un ambiente de laboratorio propio deberemos hacer la configuración manualmente.
Análogamente como hicimos con VPN, debemos instalar en CL1 el certificado de la autoridad certificadora (CA) y su correspondiente CRL. Es el mismo procedimiento ya realizado, sólo que ahora es en CL1 y por eso no agregaré más figuras, pero entiendo que es sencillo siguiendo los mismos pasos

Hecho lo anterior podemos verificar que ya se puede hacer la conexión por SSTP y IKEv2.
Lo que todavía no funciona es L2TP+IPSec. Para que este último se pueda utilizar es necesario que en CL1 se obtenga un certificado de máquina.
Esto se hace en forma análoga como hicimos con VPN, incluyendo la exportación desde la parte de usuario a la parte de máquina, a partir de lo cual CL1 se podrá conetar por L2TP+IPSec

CONCLUSIÓN 2: Tanto para SSTP como para IKEv2, sólo es necesario un certificado de máquina en el servidor VPN otorgado por una Autoridad Certificadora confiable. No es un costo excesivo

Ahora que ya podemos conectarnos usando los cuatro protocolos podemos observar qué métodos de autenticación y cifrado utiza cada uno de ellos

CONCLUSIÓN 3: Aunque PPTP es sencilla de implementar hay métodos más seguros

CONCLUSIÓN 4: La seguridad de SSTP está dada por los certificados digitales utilizados ya que usa TLS, encapsulando PPP en HTTPS

CONCLUSIÓN 5: La ventaja de SSTP está dada por usar HTTPS (TCP 443) que generalmente es un puerto abierto en los cortafuegos empresariales

CONCLUSIÓN 6: La encriptación más segura está dada por IKEv2 que utiliza AES-256

Y aún hay una ventaja más usando IKEv2, que Microsoft identifica como “VPN Reconnect”

Hagamos la siguiente prueba, conectémonos con IKEv2, bajemos el cortafuegos en SRV1, y hagamos un “ping continuo” (PING -t  192.168.1.1) desde CL1

Ahora, supongamos que con nuestra portátil (CL1) nos desplazamos y cambiamos de Access Point y por lo tanto la dirección de red de la placa real.

En las siguientes figuras podemos observar si mientras seguimos con PING cambiamos la dirección IP de la placa real, en este caso de 131.107.0.2 a 131.107.0.20

Como resumen podemos afirmar que:

CONCLUSIÓN 1: PPTP es la más fácil de implementar

CONCLUSIÓN 2: Tanto para SSTP como para IKEv2, sólo es necesario un certificado de máquina en el servidor VPN otorgado por una Autoridad Certificadora confiable. No es un costo excesivo

CONCLUSIÓN 3: Aunque PPTP es sencilla de implementar hay métodos más seguros

CONCLUSIÓN 4: La seguridad de SSTP está dada por los certificados digitales utilizados ya que usa TLS, encapsulando PPP en HTTPS

CONCLUSIÓN 5: La ventaja de SSTP está dada por usar HTTPS (TCP 443) que generalmente es un puerto abierto en los cortafuegos empresariales

CONCLUSIÓN 6: La encriptación más segura está dada por IKEv2 que utiliza AES-256

Conclusión 7: El protocolo IKEv2 además de ser relativamente sencillo de implementar y ofrecer la mejor seguridad, agrega la reconexión automática ante cualquier cambio de dirección IP