Cisco VPN IPSec Site-to-Site con Certificados Digitales (es-ES)
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:
- Metro Ethernet
- MPLS
- etc...
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. Tambin 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 utlizamos 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 modficarlas. 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 DFShttp://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/Lync_VPN_IPSec_Empresa.jpg
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:
La configuración de IPSec mediante dispositivos Cisco y solo con una IP fija en uno de los extremos es la siguiente:
| Data Center | Nueva Oficina |
|---|---|
| crypto isakmp policy 10 encr aes 192 authentication rsa-sig group 2 crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac crypto dynamic-map vpneq2b 10 set transform-set ipsec match address 180 crypto map vpnipsec 10 ipsec-isakmp dynamic vpneq2b access-list 180 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 access-list 180 deny ip 192.168.200.0 0.0.0.255 host 0.0.0.0 No NAT access-list 110 deny ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 access-list 110 permit ip any any | crypto isakmp policy 10 encr aes 192 authentication rsa-sig group 2 crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac crypto map vpneq2b 10 ipsec-isakmp set peer X.X.X.X set transform-set ipsec match address 180 access-list 180 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 180 deny ip 192.168.100.0 0.0.0.255 0.0.0.0 0.0.0.0 No NAT access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 permit ip any any |
| Por último se deben aplicar los crypto-map a las interfaces WAN | |
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:
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_45.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_46.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_47.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_48.png
Ahora debemos seleccionar **Servicio de inscripción de dispositivos de red **y pulsamo en Siguiente
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_1.png
Pulsamos en Siguiente
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_2.png
Una vez que se ha completado la instalación debemos pulsar en Configurar Servicios de certificados de Active Directory en el servidor de destinohttp://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_4.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_5.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_7.png
Introducimos el nombre del usuario del dominio (debe ser miembro únicamente del grupo de Usuarios del Dominio) e introducimos sus credenciales
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_8.png
pulsamos en Siguiente
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_9.png
Cubrimos los datos de nuestra organización y pulsamos en Siguiente
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_10.png
Podemos dejarlo por defecto y pulsamos en Siguiente
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_11.png
Por último nos muestra un resumen de la configuración y pulsamos en Configurar
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_12.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_13.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_14.png
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.
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_49.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_50.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_51.png
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 errorhttp://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_15.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_16.png
Ahora he vuelto a acceder a la URL comentada anteriormente y me muestra el siguiente errorhttp://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_17.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_18.png
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_19.png
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
De forma predeterminada, el Servicio de inscripción de dispositivos de red solamente puede almacenar en caché cinco contraseñas cada vez. Si la memoria caché de contraseñas está llena al enviar una solicitud de contraseña, debe realizar una de las siguientes acciones antes de enviar la solicitud
- 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.
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_21.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_22.png
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.
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_23.png
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**
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_24.png
4º Enviaremos la solictud de autenticación a la CA: crypto pki authenticate <nombre_trustpoint>
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_26.png
Como vemos en la URL del NDES MD5 la huella digital que nos está mostrando en la misma que nos devuelve en el router
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_27.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_28.png
Ahora si queremos ver el certificado recibido escribiremos: sh crypto ca certificates EQ2B
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_29.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_30.png
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_33.png
Esto es todo lo que debemos hacer en cada uno de los routers, estos seis pasos debemos repetirlos 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.
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_34.png
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:
May 4 15:33:57.044: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) MM_KEY_EXCH
May 4 15:33:57.044: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May 4 15:33:57.044: ISAKMP:(0):Old State = IKE_R_MM3 New State = IKE_R_MM4
May 4 15:33:57.336: ISAKMP (0:0): received packet from XXX.XXX.XXX.XXX dport 4500 sport 4500 Global (R) MM_KEY_EXCH
May 4 15:33:57.336: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
May 4 15:33:57.336: ISAKMP:(0):Old State = IKE_R_MM4 New State = IKE_R_MM5
May 4 15:33:57.336: ISAKMP:(0): processing ID payload. message ID = 0
May 4 15:33:57.336: ISAKMP (0:0): ID payload
next-payload : 6
type : 2
FQDN name : XXXXXXXXXXXXXX
protocol : 17
port : 0
length : 21
May 4 15:33:57.380: ISAKMP:(0): processing SIG payload. message ID = 0
May 4 15:33:57.412: ISAKMP:received payload type 17
May 4 15:33:57.412: ISAKMP:(0):SA authentication status:
authenticated
May 4 15:33:57.412: ISAKMP:(0):SA has been authenticated with XXX.XXX.XXX.XXX
May 4 15:33:57.412: ISAKMP:(0):Detected port floating to port = 4500
May 4 15:33:57.412: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
May 4 15:33:57.412: ISAKMP:(0):Old State = IKE_R_MM5 New State = IKE_R_MM5
May 4 15:33:57.420: ISAKMP:(0):SA is doing RSA signature authentication using id type ID_IPV4_ADDR
May 4 15:33:57.420: ISAKMP (0:0): ID payload
next-payload : 6
type : 1
address : XXXXXXXXXXXXXXXXXXXXX
protocol : 17
port : 0
length : 12
May 4 15:33:57.420: ISAKMP:(0):Total payload length: 12
May 4 15:33:57.432: ISAKMP (0:0): constructing CERT payload for hostname=EQ2B.asirsl.com,ipaddress=YYY.YYY.YYY.YYY,serialNumber=FCZ102990AA
May 4 15:33:57.432: ISKAMP: growing send buffer from 1024 to 3072
May 4 15:33:57.432: ISAKMP:(0): using the EQ2B trustpoint's keypair to sign
May 4 15:33:58.452: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) MM_KEY_EXCH
May 4 15:33:58.456: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
May 4 15:33:58.456: ISAKMP:(0):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
May 4 15:33:58.456: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
May 4 15:33:58.456: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
May 4 15:34:08.955: ISAKMP (0:0): received packet from XXX.XXX.XXX.XXX dport 4500 sport 4500 Global (R) QM_IDLE
May 4 15:34:08.959: ISAKMP: set new node 452620383 to QM_IDLE
May 4 15:34:08.959: ISAKMP:(0): processing HASH payload. message ID = 452620383
May 4 15:34:08.959: ISAKMP:(0): processing NOTIFY DPD/R_U_THERE protocol 1
spi 0, message ID = 452620383, sa = 63F8B86C
May 4 15:34:08.959: ISAKMP:(0):deleting node 452620383 error FALSE reason "Informational (in) state 1"
May 4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
May 4 15:34:08.959: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
May 4 15:34:08.959: ISAKMP:(0):DPD/R_U_THERE received from peer XXX.XXX.XXX.XXX, sequence 0x36323CCE
May 4 15:34:08.959: ISAKMP: set new node 1455114095 to QM_IDLE
May 4 15:34:08.959: ISAKMP:(0):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1
spi 1683670752, message ID = 1455114095
May 4 15:34:08.959: ISAKMP:(0): seq. no 0x36323CCE
May 4 15:34:08.959: ISAKMP:(0): sending packet to XXX.XXX.XXX.XXX my_port 4500 peer_port 4500 (R) QM_IDLE
May 4 15:34:08.959: ISAKMP:(0):purging node 1455114095
May 4 15:34:08.959: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE
May 4 15:34:08.963: ISAKMP:(0):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
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
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_52.png
Esto mismo lo podemos repetir en tantos routers como queramos conectar entre si. Esto permite aumentar el nivel de seguridad y escalabilidad de nuestra infraestructura de comunicaciones. Si os habéis fijado he puesto este comando en la configuración de solicitud de los certificados: ** revocation-check none**
crypto pki trustpoint EQ2B
** revocation-check none**
Esto evita que compruebe las CRL para saber si hemos o no revocado algún certificado, pero siempre es más que recomendable que se comprueben las CRLs. Su configuración es muy sencilla, únicamente los routers debens poder conectarse a las URLS en donde tengamos publicada la CRL y en el router cambiar ** revocation-check none** por revocation-check crl ocsp
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/vpn_con_certificados_ndes_53.png
Con esta configuración hemos logrado conectar las sedes de nuestros cliente, y además ofrecer un plus de seguridad adicional. También comentaros que si tenemos múltiples sedes, yo siempre configuro DMVPN (esto lo veremos en otro artículo) puesto que me reporta múltiples beneficios en su configuración y gestión, pero esto lo veremos en otro artículo.
Y por último, recordaros que en uno de los últimos artículos que había subido en los últimos días (Lync Server: Recomendaciones para Securizar un Trunk SIP o Direct SIP) os comentaba que siempre que configuréis un SIP TRUNK sin TLS es más que recomendable establecer un túnel IPSEC entre ambos extremos. Pues con este artículo también daríamos cabida a este escenario, nuestra infraestructura de Lync conectada a un ITSP mediante una VPN IPSec con autenticación RSA-SIG.
http://blog.asirsl.com/SiteAssets/Lists/EntradasDeBlog/EditPost/Lync_VPN_IPSec_Imagen.jpg
Existen múltiples combinaciones y formas de establecer túneles VPN, esta simplemente es una más y muy sencilla. Además, con la CA de Windows Server 2012 es muy sencillo desplegar el Servicio de inscripción de dispositivos de red (NDES) y ofrecer estos servicios de seguridad algo más avanzados.