Funcionalidad NAT/BINAT (Network Overlapping) para IPSEC en pfSense

Versión pfSense: 2.1

A partir de la versión 2.1, pfSense estrenó una nueva funcionalidad muy solicitada por los usuarios de la comunidad, que permite el nateo en origen de las redes presentadas en el dominio de encripción de las VPN IPsec.

Esta funcionalidad resuelve algunos issues con respecto al solapamiento (OverLapping) de redes en VPN IPsec, cuando se quieren vincular dos redes que utilizan la misma numeración, lo que generaría problemas de ruteo.

Para aclarar algunas dudas con respecto al funcionamiento de este feature, es importante señalar que el mismo, lo que permite es presentar la red al peer remoto, con otra numeración; pero no permite el nateo de una red que recibamos de otro peer. Entonces, si nuestra red es 192.168.0.0/24, al igual que la del otro extremo, lo que podemos hacer es presentar la red al peer remoto con el segmento que queramos, por ejempo 10.0.0.0/24, entonces en el otro extremo, para acceder al host 192.168.0.24, deberá hacerlo al host 10.0.0.24.

Hay ciertos vendors (como Cisco) que mejoran aún más esta funcionalidad y permiten que aunque el otro extremo no nos mande la red nateada, podamos hacerlo al recibirla; esta funcionalidad aún no está soportada en pfSense.

Igualmente es más que interesante aprovechar estas configuración, para poder hacer funcionar una VPN donde las numeraciónes se superpongan y no sea posible un readdressing.

Escenarios Válidos:

- Nuestra Red es 192.168.0.0/24 y queremos conectar con 2 clientes que tienen la misma numeración en los que tenemos instalados pfSense. Podemos configurar los dos pfSense de los clientes para que nos presenten las redes vía IPSEC con numeraciones diferentes por ejemplo 192.168.1.0/24 y 190.168.2.0/24. Desde nuestra Red accederemos a dichos clientes utilizando la numeración nateada, y si queremos que los clientes accedan a nuestra red, presentaremos nuestro segmento también nateado.

- Queremos que un cliente acceda a nuestra Red que es 192.168.0.0/24, pero el tiene el mismo segmento de red configurado en su lado; sin embargo no tenemos control de su firewall. Podemos presentar nuestra red nateada a otro segmento e indicar que pueden acceder utilizando dicho segmento. Nosotros no podremos acceder a su red.

Escenarios NO Validos:

- Queremos acceder a la Red de un cliente que tiene nuestra misma numeración, sin embargo no podemos solicitarle que nos natee su Red (porque no sabe hacerlo, o porque su firewall no lo soporta), y claro, no tenemos gestión de su Terminador de Túneles. En este caso, la funcionalidad de pfSense nos permitirá enlazar la VPN, pero no tendremos acceso desde nuestra Red a sus hosts, ya que sus hosts tiene la misma numeración que los nuestros. Sin embargo, ellos si podrán acceder a nuestros hosts utilizando la numeración que definimos en la configuración de NAT/BINAT en el sentido contrario.

Configuración de pfSense para NAT/BINAT:

Vamos a mostrar un escenario en el que queremos configurar una VPN entre dos pfSense, los cuales cada uno tienen una interface LAN con la red 192.168.0.0/24 (misma red en ambos extremos), y su otra interface WAN donde manejan el addressing público.

RED1 <- PFSENSE1  <– WAN –> PFSENSE2 -> RED2

RED 1 y RED 2 originalmente son 192.168.0.0/24.

Las redes Nateadas serán:

RED 1 –> 172.16.1.0/24

RED 2 –> 172.16.2.0/24

Este escenario sería el que mayor configuración en ambos extremos requiere, ya que deberemos natear ambos para que funcione, en casos más sencillos donde sólo haya que natear un sólo extremo (porque el acceso que necesitamos es únicamente de un lado hacia el otro) esta configuración también servirá, configurando sólo el extremo necesario.

1. Configuración en PFSENSE1

En el Menú de VPN, vamos a IPSec, y luego al simbolito + para agregar un tunel.

En primer lugar se setean lo parámetros de la FASE 1.

Configuramos la interface outside del pfsense para levantar la VPN (la que mira a internet) y el peer remoto (ip pública o url) y si queremos una descripción:

1

Luego siguen las opciones de Autenticación de Fase 1. Esta configuración debe ser igual en ambos extremos, no ahondaremos en este post sobre las más seguras o más eficientes configuraciones, simplemente recordar que deben ser exactamente iguales para que funcione:

2

Y por último las opciones avanzandas según nuestras necesidades. Para conectar 2 pfSense, la siguiente configuración es óptima y es recomendable que también sea igual en ambos extremos:

3

En la configuración de la FASE 2, es donde se configuran los parámetros de numeración y correspondiente NAT/BINAT:

Para hacerlas, una vez creada la Fase 1, expandimos las configuraciones de Fase 2 y vamos al + correspondiente:

45

La primer parte de la configuración es la más relevante y es donde se configura el dominio de encripción, el nateo y la red remota.

A Saber:

Local Network –> Es la red que vamos a tunelizar, la red real, que queremos que el otro extremo tenga acceso. En nuestro caso es la RED1 (192.168.0.0/24).

Podríamos tener más de una red configuradas en nuestro firewall (más de una interface), por lo que debemos elegir la que nos interese encapsular, o podríamos presentar únicamente una parte de nuestra red, por ejemplo una única /25 de nuestra /24, o únicamente 1 host. Podemos escribir la red en formato Network, en formato Host, o seleccionar la subnet correspondiente a la Interface que vamos a configurar. En este caso vamos a Seleccionar “LAN Subnet” ya que así se llama en nuestro pfSense, que sería el equivalente a escribir 192.168.0.0/24. Es lo mismo escribirla a mano o seleccionarla con el nombre de la interface, pero para mi gusto queda más prolijo y claro seleccionarla.

In case you need NAT/BINAT on this network specify the address to be translated –>  Esta configuración hace el Nateo en origen. La red anteriormente especficada (192.168.0.0/24), se presentará al otro Peer como la que definamos aca.

Es importante que si en Local Network escribimos un host, aca escribamos otro host, y si lo escribimos una red, la que setiemos acá sea del mismo tamaño ya que sino habrá problemas. (salvo que queramos presentar toda una red como un sólo host, pero esto no permitirá la comunicación bidireccional, y no es a lo que apuntamos en este post.). Por lo tanto, en este parámetro, setearemos otra red el mismo tamaño (/24), que en este caso será 172.16.1.0/24.

Remote Network –> Acá especificaremos la red que nos está presentando el otro extremo. En nuestro escenario, la red remota es 192.168.0.0/24; sin embargo, como en PFSENSE2 la vamos a presentar nateada también, la que vamos a configurar aca, es la red Nateada que en este caso es 172.16.2.0/24.

Estas 3 configuraciones son los que harán funcionar la VPN de manera correcta. En el caso de que estemos configurando una VPN sin NAT/BINAT, el segundo parámetro no lo configuraremos, y en Remote Network, configuraremos la Red Original, que no deberá solaparse con nuestra Red.

6

Siguen las opciones de Seguridad (SA/Key Exchange). Lo único que diremos en este Post es que deben ser exactamente iguales en cada uno de los extremos.  La opción de ping host, si la necesitamos, mantiene la VPN activa aunque no haya tráfico, pingeando un host específico automáticamente que debe ser accesible por el túnel:

7

2. Configuración en PFSENSE2

PFSENSE2 se debe configurar en el otro extremo de igual manera en cuanto a Fase 1 (con el peer remoto como la WAN de PFSENSE1) y Fase 2 con las opciones de Red invertidas para que la VPN levante de manera correcta.

Local Network: 192.168.0.0/24

NAT/BINAT: 172.16.2.0/24

Remote Network: 172.16.1.0/24

Una vez establecida la VPN, se podrá acceder desde la RED1 a la RED2 mediante la Red Nateada 172.16.1.0/24 y viceversa, de la RED2 a la RED1 mediante la Red Nateada 172.16.2.0/24. Esta configuración permite el diálogo bidireccional sin ningún problema.

El nateo de RED a RED, es correlativo, entonces, por ejemplo, los hosts serán:

192.168.0.1 > 172.16.1.1

192.168.0.2 > 172.16.1.2

192.168.0.3 > 172.16.1.3

192.168.0.4 > 172.16.1.4

etc…

Recordar que es necesario además la configuración de los permisos (ACLS) correspondientes para permitir el paso del tráfico que requiramos, o sea, se debe configurar en Firewall -> Rules -> IPSec, las reglas que queramos (o un any), siempre recordando que dicha configuración se aplica en la interface de origen, por lo tanto en PFSENSE1 configuraremos reglas con origen 192.168.0.0/24 y destino 172.16.1.0/24, y en PFSENSE2, reglas con origen 192.168.0.0/24 y destino 172.16.2.0/24.

Espero te haya sido util.

Gabriel Soltz

Liberada la versión 2.1 de pfSense

Ayer 15/9/2013 fue liberada la versión 2.1 de pfSense para todas las plataformas. Nosotros veníamos probándola hace un tiempo, y la ansiedad de poder aprovechar las nuevas funcionalidades y mejoras era cada vez mayor.

La actualización desde la rama 2.0.x es muy simple y en ningún momento nos topamos con problemas, ni siquiera con el inconveniente con las open-vm-tools. Fue tan fácil como “Click Here to view update.” -> “Invoke auto-update” y listo. Descarga, actualiza, reinicia, reinstala los packages, y queda andando. Todo con un mínimo corte de servicio.

Las mejoras y las nuevas funcionalidades son muchas, y algunas esperadas con ansias.

Comenzando por el sistema operativo base, la versión 2.1 está basada en FreeBSD 8.3 p13(recordemos que la versión anterior corría sobre 8.1). Esto permite subsanar al menos 3 vulnerabilidades que se hallaban en versiones anteriores del sistema operativo:

  • Desbordamiento de enteros en implementación de multicast permitía elevar privilegios — CVE-2013-3077 — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:09.ip_multicast.asc
  • Chequeo de credenciales insuficiente en ioctl permitiría denegación de servicio y ejecución de código arbitrario — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:12.ifioctl.asc
  • Debilidad en implementación de nullfs podría permitir modificación de archivos de solo lectura — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:13.nullfs.asc

Para intentar explotar estas vulnerabilidades se requería previamente acceso válido al sistema, al igual que otras vulnerabilidades anteriores, lo que reducía mucho el riesgo de ser explotadas.

 

Mejoras

La lista completa de cambios está en esta página del sitio de pfsense, pero vamos a citar sólo algunos:

  • Soporte de IPv6 para todas (o casi todas) las funcionalidades
  • Mejoras varias en la interfaz GUI
  • Múltiples portales cautivos
  • Soporte de sensores de temperatura a través de ACPI, coretemp, y amdtemp; agregado además a lista de widgets de la portada.
  • Failover multiwan de DynDNS, IPsec y OpenVPN
  • NAT antes de IPsec (1:1 o muchos:1) -> esto no lo probamos aun, pero permite manejar y acceder a redes remotas cuyos rangos de direccionamiento IP se solapan 8-)
  • OpenVPN puede aceptar atributos desde un servidor RADIUS, tales como in-acl, out-acl, servidor DNS y rutas
  • Privilegio nuevo de sólo lectura para poder asignar permisos a un usuario que no deba modificar config.xml
  • Múltiples mejoras en el logging: separación de logs de cada servicio, filtrado avanzado de logs de reglas de firewall, posibilidad de visualizar la descripción de la regla impactada, y la posibilidad de deshabilitar los logs correspondientes al tráfico generado mediante la propia administración web ;-)
  • Corrección del problema de update automático de 25 días de DynDNS y la posibilidad de establecer un intervalo de actualización. Además se agregó soporte para la versión gratuita de NO-IP y para otros proveedores. Adicionalmente, se puede habilitar el logging detallado para determinar y resolver problemas.
  • Posibilidad de capturar tráfico sin habilitar el modo promiscuo en la interfaz de red
  • Ahora el filtrado permite expresiones regulares, por ejemplo para los logs y para las ruta.
  • Se incorporaron algunos Scripts nuevos para administración vía línea de comandos (como reiniciar servicios e instalar paquetes)
  • Más módulos SNMP para monitorear
  • Pooles (rangos) DHCP adicionales al principal.
  • Mapeo estático DHCP (mac address <-> IP) ahora permite propiedades personalizadass para cada caso, por ejemplo para una mac-address determinada, además de la IP que se le asignará se le puede definir qué puerta de enlace debe usar, qué servidores DNS, etc.
  • Muchas otras mejoras y correcciones de bugs.

Todas estas mejoras no serían tanto si no fuera porque el producto es igual o más estable y performante que lo que estamos acostumbrados.

Los links de descarga son:

  • para nuevas instalaciones: http://www.pfsense.org/mirror.php?section=downloads
  • para actualizaciones http://www.pfsense.org/mirror.php?section=updates – aunque recomendamos actualizar mediante “auto update” (menú System > Firmware > Auto update)

Leonardo Brugues
@lbrug

Libros Publicados Sobre pfSense

¿ Buscabas un libro sobre pfSense ?

Los siguientes son los 2 libros publicados a la fecha. Si bien los mismos son fácilmente descargables de la red, su contenido es propietario por lo que dejo sus links para comprarlos.

 

   

pfSense 2 Cookbook

A practical, example-driven guide to configure even the most advanced features of pfSense 2

Versión en que se basa: pfSense 2.0-BETA5

Autor: Matt Williamson

Año: 2011

Link: http://www.packtpub.com/pfsense-2-cookbook/book

 

pfSense: The Definitive Guide

The Definitive Guide to the pfSense Open Source Firewall and Router Distribution

Versión en que se basa: pfSense 1.2.3

Autores: Christopher M. Buechler (co-fundador de pfSense) y Jim Pingle (consultor de pfSense)

Año: 2009

Link: http://www.amazon.com/pfSense-Definitive-Christopher-M-Buechler/dp/0979034280

 

¿ Conocés algún otro ?

Compartilo !

 

 

Autor: Gabriel Soltz

 

SI TE GUSTÓ ESTE ARTÍCULO,

HACÉNOSLO SABER CON UNA DONACIÓN A LA SIGUIENTE DIRECCIÓN BITCOIN:

[btcpayments address="1LTixtMfXWX8r6gczaKZL68xkh6cudBQGf"]

Implementación de VPN Cliente-Servidor con OpenVPN y pfSense

Versión pfSense: 2.0.3
Módulos:
OpenVPN Client Export Utility 1.0.11

En el siguiente artículo se explica la implementación de la función de terminación de túneles Cliente-Servidor con OpenVPN y pfsense, cuya funcionalidad es implementada nativamente en las actuales versiones.

OpenVPN fué creado en 2001, y actualmente es el estandar a nivel seguridad y performance habiendo desplazado a protocolos como PPTP y L2TP que demostraron ser vulnerables y no tan rápidos.

En los siguientes links puedes encontrar comparativas entre OpenVPN, L2TP y PPTP: link1 y link2

OpenVPN es actualmente compatible con todos los sistemas operativos.

Autenticación:

OpenVPN implementa SSL/TLS mediantes certificados RSA que se considera mucho más seguro que la utilización de claves precompartidas. Es posible también la implementación de OpenVPN en conjunto con LDAP o Radius para el manejo de usuarios y permisos, pero en este tutorial se utilizará la autenticación Local en el pfSense. Vamos a necesitar:

- Certificado Raiz, utilizado para generar los certificados clientes, en nuestro caso generaremos uno propio, por lo tanto seremos nuestra propia entidad certificadora, sin embargo también se podría utilizar una CA externa. [OpenVPN-CA]

- Certificado Cliente para el pfSense, que únicamente deberá estar en el pfSene. [OpenVPN-Servidor]

- Certificados Clientes para usuarios, es necesario un certificado para cada usuario que daremos acceso. [OpenVPN-Gabriel]

Clientes:

Mediante el paquete “OpenVPN Client Export Utility” es posible generar paquetes instaladores para cada usuario desde el pfSense que configuraran las pc clientes de manera muy sencilla: básicamente el paquete está conformado por el instalador de openvpn, el archivo de configuración con los datos de la vpn y los certificados necesarios para conectarse al servidor. Sin embargo, el plugin no siempre mantiene las últimas versiones de los instaladores; si se va a utilizar es recomendable chequear que no estén defasadas las versiones.

Para evitar este problema, en nuestro caso utilizamos el plugin únicamente para generar el zip con la configuración para cada usuario (certificados + archivo de configuración), que simplemente hay que copiar en la carpeta de configuración del cliente para funcionar.

Servidor:

Es posible configurar más de un servidor de OpenVPN en un mismo pfSense con diferentes configuraciones (por ejemplo diferentes métodos de autenticación, diferente configuración de puertos, diferentes redes a las que dará acceso, etc).

Topología:

Nuestro pfSense cuenta con 3 Interfaces: WAN (numeración pública), LAN (segmento de usuarios en la red) y DMZ (segmento de servidores en la red). La configuración que crearemos dará acceso a la red LAN (192.168.1.0/24).

Resumen:

Los pasos para esta implementación son:

1. Creación de Certificado Raiz (CA)

2. Creación de Certificado Servidor

3. Configuración del Servidor

4. Creación de Usuario + Certificado

5. Instalación de Cliente

Implementación:

Utilizaremos el Wizard propio de pfSense que simplifica el paso 1, 2 y 3. Para comenzar vamos al menú VPN, luego OpenVPN y por último a la solapa Wizards, que nos abrirá el asistente de configuración.

1. Seleccionamos el tipo de Servidor, que en nuestro caso será Local User Access, ya que los usuarios los crearemos y manejaremos mediante el pfSense. Como explicamos antes, también es posible configurarlo con un servidor LDAP o Radius. Next.

2. El próximo paso será la configuración del Certificado Raiz (la entidad certificadora).Este certificado será utilizado para luego crear el certificado del servidor y los certificados de usuarios.

Si ya existen CAs cargados en el pfSense el asistente nos dejará seleccionar uno (los mismos se pueden crear desde el menú System –> Cert Manager) o también crear uno nuevo; y en caso de no existir ninguno como en el nuestro, directamente nos llevará a la creación de uno:

Completar la información requerida respecto a la organización, el Key Lenght recomiendo utilizar 2048 ya que es optimizado entre seguro y performante, y el Lifetime es el tiempo de validez. Add new CA.

3. Ahora es necesario crear el certificado para el servidor, que será creado en base a la entidad certificadora creada en el paso anterior.

Si ya existieran certificados creados podríamos simplemente seleccionar uno, en nuestro caso, nos llevará directo a la creación de uno. La mayoría de los datos ya estarán completos basados en los datos de la CA. Faltaría completar el nombre y un correo.

Con los datos completos le damos click a Create new Certificate.

4. A cotinuación el asistente nos lleva a la configuración del Servidor, que se divide en 4 grupos:

General OpenVPN Server Information:

Contiene la configuración de la interface que atenderá las conexiones (en nuestro caso llegarán desde internet a la interface wan), el puerto y el protocolo que utilizaremos, en nuestro caso los default (en caso de cambiarlos, será necesario también cambiarlos en los clientes). No está demás aclarar, que si quisieramos agregar otro Servidor VPN (algo así como otra instancia de OpenVPN), tendremos que elegir otro puerto.

También será necesario una regla de firewall que permita las conexiones entrantes a ese puerto y procolo en la interface WAN, que crearemos luego.

Cryptographic Settings:

La configuración criptográfica que utilizaremos es la default, ya que nuevamente consideramos que brinda un buen nivel de seguridad y de performance.

Tunnel Settings:

Aquí setearemos la configuración propia del tunel, esta configuración es importante.

Tunnel Network, será la red que crearemos para los clientes que se conecten. Por lo tanto, con esta configuración estamos definiendo el rango de numeración que se le asginarán a los clientes al conectarse y también la ip de la interface virtual que será la primera de dicha red. Se deberá utilizar una red que no esté ya utilizada para evitar problemas de ruteo. En nuestro caso utilizaremos 10.0.1.0/24 (entonces, la interfaz virtual que se creará tendrá la 10.0.1.1 y los clientes que se conecten tendrán una dirección asignada entre la 10.0.1.2 y la 10.0.1.254).

Local Network, define la red a la que daremos acceso y que por ende, será ruteada en los clientes a través de la vpn. En nuestro caso, tal cual los descripto en el apartado Topología, configuraremos la red 192.168.1.0/24.

También se puede utilizar la opción Redirect Gateway, que lo que hará básicamente es rutear todo el tráfico del cliente por la VPN, esto hará que todas las conexiones que se generen se envien al tunel, incluso por ejemplo las peticiones a numeración pública (navegación web por ejemplo), entonces utilizará la salida del pfSense también para navegar. A veces se utiliza este método para dar un mayor nivel de seguridad a la red, evitando que el usuario “puentee” su salida a internet con la red a la que se está conectando saltéandose las restricciones que por ejemplo puedan estar configuradas en el proxy de navegación web. Nosotros no utilizaremos está opción para evitar que se utilice nuestra salida a internet para navegar u otros, y que el usuario únicamente nos envíe el tráfico destinado a nuestra red.

Podemos agregar un límite de conexiones concurrentes como medida de seguridad adicional o para asegurar la performance del equipo (cuanto más usuarios conectados, mayor uso de procesador).

También habilitaremos la compresión que hace mucho más performante la conexión.

Client Settings:

Por último las configuraciones que afectarán a los clientes que se conecten. Setearemos la opción Adress Pool, que afirma la configuración del Tunnel Network, o sea, hahbilita a que los clientes reciban una ip de la red definida (10.0.1.0/24). Si no caerían con su numeración pública, y esto es algo que no queremos porque perdemos control, por ejemplo a nivel acls.

Además setearemos el servidor dns, que en nuestro caso es el propio pfSense, para que el cliente pueda resolver nombres internos.

No necesitamos setear nada más, por lo que damos  a la opción Next.

5. El próximo paso nos permite agregar automáticamente la regla que permite el tráfico desde internet al puerto y protocolo configurado en el paso anterior.

Además nos permite agregar o no, una regla en la nueva interface que creará el pfSense, la 10.0.1.0/24, donde caerán los usuarios conectados, si seleccionamos esta opción, la regla que se creará sera de origen ANY, destino ANY, y puerto y protocolo también ANY. Ya que nosotros no quremos dar acceso a los usuarios que se conecten a la red DMZ y sólamente a la red LAN, no seleccionaremos esta opción y crearemos la regla a mano. Pueden seleccionar esta opción si no desean aplicar restricciones.

Cuando le demos Next, el asistente finaliza e indica que fué configurado el servidor correctamente.

6. Si ahora vamos al menú Firewall, y luego a Rules, veremos que se ha agregado la regla en la interface WAN, que permite todas las conexiones al puerto UDP/1194 y además que se ha creado una nueva solapa OpenVPN, donde manejaremos las reglas asociadas a todos los servidores OpenVPN:

Cuando vayamos a la solapa OpenVPN, estará vacía sin ninguna regla, pero en caso de que hayan seleccionado la opción que crea la regla automáticamente, aparecerá una regla permitiendo todo el tráfico. Nosotros creamos la regla a mano y quedará de la siguiente forma:

 

Usuarios:

Ahora crearemos un usuario habilitad0 para conectarse, en nuestro caso también generaremos un grupo OpenVPN, para incluir en el a este usuario y a todos los que creemos para conectarse a la VPN. Esto sirve para que administrativamente sepamos que usuarios tienen acceso a la VPN, además de poder asginar permisos de pfSense a todos los usuarios a la vez, por ejemplo para permitir el acceso a algún módulo de pfSense como el de cambio de Password.

1. Vamos al menú System, User Manager y luego a la solapa Groups. Allí buscamos el ícono de agregar (+) y creamos el grupo:

Le damos Save para crear.

2. Para crear un usuario, volvemos a la solapa Users, y nuevamente vamos al ícono de agregar (+):

Configuraremos las opciones básicas como el nombre de usuario, el nombre completo, la contraseña, la asociación al grupo que creamos antes, y en nuestro caso también seteamos una fecha de expiración que será a fin de año.

Seleccionamos la opción de crear certificado, y nos expanderá más opciones:

Debemos poenerle un nombre al certificado y elegir la entidad certificadora que creamos anteriormente.

Le damos Save y nos creará el usuario y su certificado automáticamente.

Podemos ir luego al menú System, a la opción Cert Manager para comprobarlo.

En la solapa CA, veremos la entidad certificadora que creamos:

Y en la solapa Certificates veremos el certificado del Servidor que creamos anteriormente, y el certificado del usuario gabriel que acabamos de crear. (También veran un certificado default que es que se utilizan al conectarse vía HTTPS al WebConfiurator).

 

Clientes:

El servidor ya se encuentra configurado y el usuario creado, ahora nos toca configurar el cliente que se conectará con el usuario gabriel.

Para esto es necesario instalar el cliente OpenVPN en el o los equipos que se conectarán y luego cargarle la configuración del servidor y la del usuario.

Para ayudarnos en la configuración de los clientes, instalaremos también el paquete “OpenVPN Client Export Utility” que nos permite exportar los zips de configuración para cada usuario de manera muy sencilla.

Por lo tanto, en primer lugar, instalemos el paquete desde el menú System, opción Packages y luego la solapa Available Packages. Buscamos el paquete y le damos al ícono de agregar (+).

Una vez instalado, se agrega en el apartado de OpenVPN (menú VPN, opción OpenVPN), una nueva solapa Client Export:

Si hicimos todo bien, en la parte de abajo de la página, veran un apartado con los nombres de usuario que están asociados al certificado de la VPN y de donde podremos exportar los clientes para cada sistema operativo, o la “Standard Configuration” que nos da un zip con el archivo de configuración de openvpn (*.opvn) y los certificados del usuario para permitir la conexión, este zip debe incorporarse a la carpeta de configuración del cliente OpenVPN de la pc que va a realizar la configuración y con esto ya se podrá conectar.

Veremos algunos ejemplos de configuración de clientes:

Instalación de Cliente OpenVPN en Windows

Existen dos clientes OpenVPN para Windows, el oficial (http://openvpn.net) y un Cliente llamado OpenVPN Manager (https://github.com/jochenwierum/openvpn-manager/), este segundo cliente, soluciona un problema conocido cuando el usuario no tiene permisos de administrador en la PC con la que se quiere conectar al servidor. Para funcionar la conexión, el cliente a conectar debe poder agregar ruteos (como ya explicamos en la configuración del Servidor) para conocer la red a la que se quiere acceder a través del tunel que se levantó. Sin permisos de administrador, no es posible realizar esa configuración, y OpenVPN Manager soluciona esta limitación mediante la creación de un servicio específico que se encarga de dicha configuración.

En caso de no contar con permisos de administrador, se debe utilizar ese cliente que se descarga acá (http://openvpn.jowisoftware.de/downloads/), y además, antes de exportar la configuración, se debe tildar la opción Management Interface OpenVPNManager, que adapta la configuración para este cliente:

En nuestro caso, tenemos permisos de administrador en el equipo Windows que se conectará por lo que no utilizaremos la anterior opción, y aprovecharemos el cliente original de OpenVPN, que realmente es un poco más performante que el OpenVPN Manager, y además, se actualiza con mayor periodicidad.

1. Descargamos el Cliente OpenVPN desde el sitio oficial http://openvpn.net/index.php/open-source/downloads.html. Tenemos disponible la versión de 32 o 64 bit, según corresponda. Descargamos la necesaria.

2. Realizar la instalación. La misma instalará una nueva interface, por lo tanto será necesario permisos de administrador para hacerlo, que  solicitará durante el proceso.

3. Finalizada la instalación, hay que ir al PATH de instalación y a la carpeta Config, en nuestro caso es C:Program FilesOpenVPNconfig, allí copiamos los archivos de configuración y certificados que descargamos con el OpenVPN Client Export Utility.

Con esto ya es suficiente para conectarse a la VPN creada.

4. Ejecutamos el cliente OpenVPN GUI, que se abrirá y se mantendrá minimizado en la barra del reloj. Al hacer click con el boton derecho sobre el mismo, tendremos la opción Connect (en caso de que tengamos más de una configuración VPN, veremos todas las disponibles con su respectiva opción Conect).

Hacemos click en la opción Conect para conectarnos.

La conexión se establece y vemos que nos asigna una ip del rango que habíamos configurado en la configuración del Servidor:

Si revisamos como quedó la tabla de ruteo en la PC conectada, veremos que se ha agregado la ruta a la red 192.168.1.0/24 por la interface de VPN:

 

Autor: Gabriel Soltz

 

SI TE GUSTÓ ESTE ARTÍCULO,

HACÉNOSLO SABER CON UNA DONACIÓN A LA SIGUIENTE DIRECCIÓN BITCOIN:

[btcpayments address="1AtS1DY6kRZ6zhUSkB48AxsgqQTyhpfFQg"]

Incio

Bienvenido !

Estamos creando la primer comunidad de pfsense en Latinoamérica.

El objetivo de este sitio será la promoción del uso de herramientas libres en todo latinoamérica mediante la producción de contenido de investigación que permita a los usuarios aprender a reemplazar tecnologías pagas como Cisco, Fortinet y Checkpoint, con tecnologías de código abierto y gratuitas.

Nos enfocaremos en producir material a la comunidad gratuito y de calidad, que permita la implementación de infraestructuras de alta seguridad y disponibilidad, sin dependencia de proveedores caros como actualmente se está acostumbrado.

Tenemos extensa experiencia en la implementación de este tipo de soluciones en pequeñas, medianas y grandes empresas, obteniendo excelentes resultados, que les permitirieron alcanzar altos estandares de seguridad avalados por certificaciones como 27002, SOX, PCI, HIPPA entre otras, ahorrándose los costos conocidos de proveedores de tecnologías propietarias.

Si querés conocer más sobre los autores de este blog, consulta la sección Autores.

Esperamos que este sitio sea de tu utilidad y consulta frecuente.

Si te interesa participar contactate.