En este post vamos a ver como configurar una VPN IPSEC de acceso remoto en un firewall Fortigate, con este tipo de VPN usando el protocolo IPSec nos podemos conectar desde cualquier equipo con conexión a Internet hacia nuestra red interna, dónde todo el tráfico irá encriptado.

• Lo primero que vamos a realizar será, crear los usuarios locales que accederán a través de la VPN:

• Para una correcta administración, los usuarios que nos hemos creado anteriormente los vamos a anidar en un grupo:

• Una vez creados los usuarios y grupos, vamos a crearnos el túnel IPSec, para ello, accedemos a VPN > Túneles Ipsec > Crear nuevo > IPsec Tunnel:

• Sobre Configuración de VPN, le indicamos un nombre y seleccionamos Acceso remoto, Siguiente:

• Sobre Autenticación, le indicamos la interface de entrada, el método de autenticación por llave compartida y el grupo de usuario, este grupo lo eliminaremos de la configuración de las fases más tarde, ya que las políticas de acceso irán configuradas con grupos y no sería necesario, Siguiente:

• Sobre Política y Enrutamiento, vamos a configurar esta política, que más tarde vamos a eliminar, ya que iremos aplicando políticas más granulares y restrictivas, habilitamos el Split Tunnel, esto hará que los usuarios que se conecten a la VPN, tengan la salida a Internet por su propia conexión y no por la nuestra, Siguiente:

• Sobre Opciones de cliente, le indicamos que guarde la contraseña, y habilitamos el Keep Alive, Crear:

• Aquí nos indica todo lo que hemos configurado, damos a Mostrar la lista de túnel:

• Vemos el túnel IPsec que nos ha creado, damos a Editar:

• Convertimos a túnel personalizado:

• Para la parte de Red, configuramos estos parámetros:

• Para la parte de Autenticación, configuramos lo siguiente:

• Para la propuesta de la fase 1, configuramos estos parámetros:

• Para XAUTH, aquí es donde quitamos el grupo que configuramos al crear el túnel, y para el Grupo de Usuarios, le indicamos que los herede de las políticas:

• Para los Selectores de fase 2, configuramos estos parámetros, damos a OK:

• Aquí tenemos ya el túnel IPsec configurado de modo personalizado:

• Antes de seguir, vamos a explicar, estos dos objetos que se han creado al crear la VPN IPsec.
• Uno de ellos es, ipsecra_range, este objeto es para asignar las direcciones IPs de los equipos que se conecten a nuestra VPN PIsec de acceso remoto:

• El otro es, ipsecra_split, este objeto es un grupo de direcciones que actúa como una «lista blanca» de destinos, su función principal es decirle al cliente VPN (FortiClient) qué tráfico debe enviar obligatoriamente a través del túnel y cuál debe ignorar para que salga por su conexión local a Internet.
• Cuando habilitamos el Split Tunneling (Túnel Dividido), el comportamiento es el siguiente:
• Si el destino está en el objeto ipsecra_split, el FortiClient enruta ese tráfico por la VPN.
• Si el destino NO está ahí, el FortiClient lo envía por la puerta de enlace predeterminada del usuario (su internet doméstico).

• También podemos ver, que en la interface de red que le indicamos al túnel VPN IPsec, nos ha creado esta interface virtual:

• Para terminar de configurar la VPN IPsec de acceso remoto, debemos de crear las reglas o políticas para que los equipos que se conecten a través de la VPN, tengan acceso a las redes internas configuradas en nuestro firewall, voy a mostrar sólo una de ellas ya que para las demás sería exactamente igual, editamos la regla que se nos creó al crear el túnel IPsec:

• Con esto ya tendríamos configurada y operativa nuestra VPN IPsec de acceso remoto, ahora desde cualquier equipo con conexión a internet, le instalaremos el Forticlient y configuraremos los parámetros de la VPN IPsec para conectarnos desde cualquier lugar del mundo a las redes internas de nuestra infraestructura, dónde todo el tráfico irá encriptado mediante IPsec:

• Como podemos ver ya estamos conectados y nos está sirviendo una dirección IP del rango que habíamos configurado:

• Aquí vemos el túnel levantado:

• Desde el Monitor IPsec de nuestro Fortigate podemos ver los usuarios conectados a través de la VPN:

• Desde la opción VPN > VPN Location Map podemos ver desde que parte del mundo se están conectando los usuarios que hemos creado y configurado para nuestra VPN IPsec de acceso remoto:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo desplegar y configurar dos firewalls OPNSense en modo clúster HA en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar es acceder a este link de dmauser, aquí vamos a encontrar un desarrollo para desplegar dos firewalls OPNSense sobre FreeBSD en modo cluster HA Activo-Activo:

• Se nos abrirá esta plantilla para el despliegue de OPNSense, sobre Deployment Scenarios le indicamos la suscripción, el grupo de recursos, la región y muy importante OPNSense Scenario que le indicamos Active-Active:

• Sobre Virtual Machine Settings le indicamos el nombre y tamaño de máquina, la URL para la descarga del script, la versión de OPNSense y la versión del agente de Azure:

• Para el despliegue y la configuración de la red virtual en Azure, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales (ésta última la configuraremos a posteriori de la plantilla de despliegue):
• Red virtual: opnsenseha-vnet168.128.0/18
• Subred Externa: Untrusted-Subnet168.191.0/27
• Subred Interna: Trusted-Subnet168.191.32/27
• LAN Azure: SubnetLAN-192_168_128_0-24
• DMZ Azure: SubnetLAN-192_168_129_0-24

• Sobre Virtual Network Settings estas serían las configuraciones para nuestra infraestructura:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, comenzamos a Crear todos los recursos de la plantilla OPNSense deployment:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente, podemos ver, los distintos recursos que ha creado el despliegue de esta plantilla:

• Accedemos al grupo de recursos y vemos todos los recursos que se nos han creado, entre ellos, dos firewalls opnsense (primario y secundario), dos Load Balancer (Externo e Interno) y una IP pública:

• Ahora vamos a clicar sobre la máquina virtual opnsense-Primary:

• En la máquina virtual accedemos a Configuración de red y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN de OPNSense que tiene asignada una IP privada del rango de la subred Untrusted, y la otra es la interface LAN que tiene asignada una IP privada del rango de la subred Trusted:

• Debemos de configurar las IPs privadas como estáticas, tanto la WAN cono la LAN:

• Para la máquina opnsense-Secondary hacemos lo mismo:

• Otro de los recursos que se han creado es el Load Balancer Interno:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP del rango de la subred Trusted:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Trusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada para equilibrar la carga entre los dos firewalls:

• Otro de los recursos que se han creado es el Load Balancer Externo:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP pública, que será la que nos dará la entrada y salida desde y hacia la WAN:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Untrusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada a modo de ejemplo para definir cómo se distribuye el tráfico entrante a todas las instancias del grupo de back-end, en este ejemplo sería una regla creada en el puerto 3389 para equilibrar la carga del tráfico RDP:

• Sobre Regla NAT de entrada, tenemos dos reglas configuradas para el acceso a los firewalls opnsense a través de su IP pública, al firewall primario se accede por el puerto 50443 y al firewall secundario por el puerto 50444, que como vemos está mapeado al puerto 443 de cada firewall:

• Sobre Reglas de salida, tenemos configurada una regla para la salida a la WAN de nuestra infraestructura, con esta regla todas las máquinas ubicadas detrás de los firewalls van a salir a Internet con la IP pública de nuestro load balancer externo:

• Para acceder a los firewalls accedemos a través de su IP pública, https://PublicIP:50443 para el primario y https://publicip:50444 para el secundario, las credenciales por defecto son root/opnsense:

• Lo primero que vamos a configurar en los firewall opnsense, va a ser la configuración de HA.
• Nos vamos primero al firewall primario y sobre System > High Availability > Settings configuramos el peer del firewall secundario:

• Ahora accedemos al firewall secundario y sobre System > High Availability > Settings configuramos el peer del firewall primario:

• Accedemos de nuevo al firewall primario y sobre System > High Availability > Status sincronizamos y reconfiguramos todo, una vez configurado este cambio, todo lo que hagamos y configuremos en el firewall opnsense primario se va a replicar en el firewall opnsense secundario:

• Veamos un ejemplo, hemos configurado los servidores NTP en el firewall primario:

• Sincronizamos todos los servicios:

• Una vez que se ha sincronizado todo, si accedemos al firewall secundario, vemos que la configuración de los servidores NTP se ha replicado correctamente:

• Como comentamos anteriormente, vamos a configurar la red local de Azure dónde se conectarán nuestras máquinas virtuales, LAN Azure: SubnetLAN-192_168_128_0-24 y DMZ Azure: SubnetDMZ-192_168_129_0-24:

• Lo siguiente que vamos a desplegar y configurar es una tabla de rutas UDR (User Definition Routes) en Azure.
• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar las subredes LAN y DMZ que configuramos anteriormente, estas subredes son dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya las tenemos asociadas:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas > Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred LAN dónde vamos a ubicar nuestras máquinas virtuales:

• La siguiente ruta será para el acceso a la subred DMZ dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Sobre Información general en la tabla de rutas, podemos ver, todo lo que se ha configurado:

• Una vez configurada la tabla de rutas, accedemos a nuestro OPNSense HA en Azure, y nos vamos a crear estas dos rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del OPNSense lo envíe por la interface WAN al gateway de la subred Untrusted, y la segunda ruta son para servicios internos de Azure, para que lo envíe por la interface LAN al gateway de la subred Trusted:

• Para todas las demás configuraciones de opnsense, podemos seguir los enlaces a estos post creados hace algún tiempo en el blog.

Saludos y espero que os sea de ayuda

En este post vamos a ver como montar un FrontalWeb con Apache (Reverse Proxy) sobre una máquina Ubuntu Server 24.04 LTS utilizando certificados de Let´s Encrypt, con esta implementación le vamos a dar un punto más de seguridad a nuestra infraestructura perimetral, ya que sólo vamos a exponer directamente a Internet un único servidor, sólo va a ser necesario abrir un puerto en nuestro Firewall, ya que a través del Frontalweb vamos a poder alcanzar a los demás servidores, los certificados digitales los vamos a instalar y administrar en un solo servidor, a través del Frontalweb que se va a encargar de cifrar todos los contenidos.

• Lo primero que vamos a realizar será la instalación de Apache, para ello ejecutamos el comando apt-get install apache2:

• Una vez finalizada la instalación, con el comando apache2ctl -v podemos ver la versión de apache que hemos instalado:

• Con el comando ufw app list podemos ver los perfiles de aplicación que se pueden usar para habilitar o deshabilitar el acceso a Apache a través del firewall de Ubuntu:

Apache → Este perfil solo abre el puerto 80 (tráfico web normal sin cifrar)

Apache Full → Abre tanto el puerto 80 (tráfico web normal sin cifrar) como el puerto 443 (tráfico cifrado TLS / SSL)

Apache Secure → Este perfil solo abre el puerto 443 (tráfico cifrado TLS / SSL)

• En nuestro caso vamos a permitir el acceso a los dos puertos (80 y 443), ufw allow ‘Apache Full’:

• Para verificar que el servidor Apache está funcionando, accedemos a la URL de nuestro servidor, http://frontalweb.ragasys.net:

• Con el comando systemctl status apache2 podemos ver el estado del servicio del servidor Apache, que como podemos ver está activo y ejecutándose:

• Una vez que hemos instalado nuestro servidor de apache, vamos a habilitar los siguientes módulos:
• a2enmod ssl
• a2enmod proxy
• a2enmod proxy_http
• a2enmod proxy_balancer
• a2enmod lbmethod_byrequests
• a2enmod headers
• a2enmod rewrite

• Con el comando systemctl restart apache2 reiniciamos el servicio:

• Nos vamos a crear nuestro primer VirtualHost, en la ruta /etc/apache2/sites-available, y ejecutando nano nextcloud.ragasys.eu.conf, este primer VirtualHost será un servidor de Nextcloud que tenemos en nuestra infraestructura, con este fichero, todo el tráfico http y https que llegue a la URL de dominio púbico indicada, se va a redirigir al servidor interno de nextcloud, siempre a través de conexión cifrada https:

<VirtualHost *:80>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

#RewriteEngine On
#RewriteCond %{HTTPS} off
#RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

#SSLEngine on
#SSLCertificateFile /etc/letsencrypt/live/nextcloud.ragasys.eu/fullchain.pem
#SSLCertificateKeyFile /etc/letsencrypt/live/netxcloud.ragasys.eu/privkey.pem

ProxyPreserveHost On
ProxyPass / http://nextcloud.ragasys.net/
ProxyPassReverse / http://nextcloud.ragasys.net/

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Nos creamos nuestro segundo VirtualHost, en la ruta /etc/apache2/sites-available, y ejecutando nano guacamole.ragasys.eu.conf:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

#RewriteEngine On
#RewriteCond %{HTTPS} off
#RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

#SSLEngine on
#SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
#SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem

ProxyPreserveHost On
ProxyPass /guacamole http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse /guacamole http://guacamole.ragasys.net:8080/guacamole/

ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Nos creamos también el directorio para los logs de los sites virtuales:

• Habilitamos los VirtualHost con el comando a2ensite nextcloud.ragasys.eu.conf y a2ensite guacamole.ragasys.eu.conf y como podemos ver ya tenemos habilitados los sites:

• Deshabilitamos el site por defecto a2dissite 000-default.conf:

• Ejecutamos systemctl restart apache2 y systemctl status apache2 para reiniciar y ver el estado del servicio:

• Ahora en nuestro Firewall, que en mi caso es un Fortigate, nos debemos de crear las reglas necesarias para publicar el puerto 443 apuntando al servidor FrontalWeb que va a ser el único que vamos a exponer en el perímetro, en este post de este mismo blog podemos ver como hacerlo, primero realizamos un NAT estático y luego nos creamos la regla de acceso a los puertos HTTP y HTTPS para el NAT estático creado:

• En nuestro DNS interno debemos de crearnos una zona de búsqueda directa, en mi caso, ragasys.eu, que es el dominio externo que hemos comprado a nuestro proveedor de DNS y que utilizaremos para publicar nuestros servicios, esto lo hacemos en nuestra infraestructura interna, para que los usuarios que accedan desde la red interna no salgan al exterior, en esta zona de búsqueda directa nos creamos estos registros Tipo A y CNAME: 

• En nuestro DNS externo, el que tengamos contratado con nuestro proveedor de DNS, debemos de hacer algo parecido, es decir, debemos de crearnos un subdominio del tipo www.ragasys.eu con un registro tipo A apuntando a nuestra IP púbica, y nos crearemos subdominios por cada servicio que queramos publicar con un registro del tipo CNAME apuntando a www.ragasys.eu:

• Ahora vamos a instalar cerbot, para ello, ejecutamos apt install certbot python3-certbot-apache:

• Obtenemos el certificado SSL de Let’s Encrypt para el primer site, para ello, ejecutamos certbot –apache -d nextcloud.ragasys.eu:

• Obtenemos el certificado SSL de Let’s Encrypt para el segundo site, para ello, ejecutamos certbot –apache -d guacamole.ragasys.eu:

• Si accedemos a la configuración de los sites virtuales, nos ha quedado así tras el despliegue de los certificados SSL de Let’s Encrypt:

• El fichero bien estructurado del primer site debe quedar así:

<VirtualHost *:80>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

RewriteEngine on
RewriteCond %{SERVER_NAME} =nextcloud.ragasys.eu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/nextcloud.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
ProxyPass / http://nextcloud.ragasys.net/
ProxyPassReverse / http://nextcloud.ragasys.net/

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/ssl-access.log combined
</VirtualHost>

• El fichero bien estructurado del segundo site debe quedar así:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

RewriteEngine on
RewriteCond %{SERVER_NAME} =guacamole.ragasys.eu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
ProxyPass /guacamole http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse /guacamole http://guacamole.ragasys.net:8080/guacamole/

ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• El fichero de este segundo host me ha estado dando problemas, y no conseguía acceder, se iba siempre a la página por defecto de apache.
• Para dejarlo fino y funcionando, se ha quedado así de manera definitiva:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

RewriteEngine on
RewriteRule /(.*) https://guacamole.ragasys.eu/guacamole [R,L]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
SSLProxyEngine On
RewriteEngine On

<Location />
ProxyPass http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse http://guacamole.ragasys.net:8080/guacamole/
</Location>
ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Certbot renueva los certificados automáticamente, pero podemos verificarlo con, certbot renew –dry-run:

• Aquí vemos que ya podemos acceder a nuestro servidor de Nextcloud desde el exterior, a través del FrontalWeb, con los certificados SSL de Let’s Encrypt: 

• Aquí vemos que ya podemos acceder a nuestro servidor de Apache Guacamole desde el exterior, a través del FrontalWeb, con los certificados SSL de Let’s Encrypt:

• Para comprobar el certificado podemos acceder a  https://www.ssllabs.com/ssltest/ y verificamos el certificado para nuestros dos sitios webs:

Saludos y espero que os sea de ayuda

En este post vamos a ver como crear reglas del firewall en nuestro vCenter para limitar y supervisar el acceso a la plataforma.

• Para todo el tráfico de red entrante en el firewall se pueden aplicar esta acciones:
• Aceptar, permite el paquete con la dirección correspondiente.
• Omitir, descarta el paquete con la dirección correspondiente.
• Rechazar, descarta el paquete con la dirección correspondiente mientras que no se puede acceder al destino de envío.
• Regresar, aplica reglas predeterminadas o específicas del puerto en un paquete con la dirección correspondiente.

• Para configurar reglas de firewall accedemos a la interface VAMI y accedemos a Firewall > AGREGAR:

• Vamos a crear una regla para permitir el acceso desde una determinada IP:

• Y otra regla para denegar todo lo demás:

• Aquí tenemos las dos reglas creadas:

• Ahora si accedemos por SSH a nuestro vCenter y hacemos un iptables -L veremos que ya tenemos estas dos reglas agregadas, me muestra el nombre asignado a esa IP ya que tengo configurado DNS en el vCenter y está resolviendo esa IP:

• Con estas dos reglas le estamos indicando al vCenter que sólo será accesible desde la IP 192.168.14.14, aquí ya configuramos las reglas que nos vengan bien, y vamos añadiendo las que nos vayan haciendo falta, luego con REORDENAR podemos ponerla en el orden que nos venga bien:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar SD-WAN (Software-Defined WAN) en firewalls fortigate.

SD-WAN es una interface virtual compuesta por 2 o más interfaces con acceso a Internet, el objetivo de SD-WAN es hacer un uso mucho más efectivo de nuestras conexiones hacia internet aplicando diferentes criterios de balanceo.

• Antes de empezar vamos a ver las interfaces de red que tenemos configuradas en nuestro firewall, para ello, accedemos a Network > Interfaces y vemos que ya tenemos configuradas la interface LAN y dos interfaces WAN para la salida a Internet, estas dos interfaces son las que vamos a configurar para la SD-WAN:

• Para empezar a configurar SD-WAN accedemos a Network > SD-WAN y la configuramos manualmente:

• Sobre SD-WAN Zones podemos ver que hay creada ya una interface virtual, podemos utilizar esta interface y añadirle los miembros y empezar a trabajar, pero en nuestro caso nos vamos a crear una nueva zona y le vamos a añadir como miembros nuestras dos interfaces WAN:

• Le indicamos un nombre y OK:

• Aquí vemos que ya la tenemos creada:

• Ahora vamos a añadir y configurar las interfaces miembros de esta nueva zona SD-WAN, para ello, accedemos a Create new > SD-WAN Member:

• Añadimos las dos interfaces WAN que tenemos en nuestro firewall, indicándole la zona, la puerta de enlace, el costo y la habilitamos:

• Vemos que ya tenemos la zona creada con nuestras dos interfaces WAN:

• Si accedemos de nuevo a Network > Interfaces podemos ver la interface virtual para la nueva zona SD-WAN y las interfaces que la componen (WAN1 y WAN2):

• El siguiente paso será crearnos la ruta estática por defecto para la salida a Internet por la SD-WAN, para ello, accedemos a Network > Static Routes > Create new y creamos la ruta por defecto para la SD-WAN:

• Aquí vemos que ya la tenemos creada:

• Para verificar que funciona, desde la CLI le hacemos un ping a google.com y vemos que ya recibimos respuesta:

• Empezamos a ver tráfico sobre la SD-WAN, de momento sólo hay tráfico por la WAN1 ya que no tenemos configuradas las performance SLAs, entonces no estamos aplicando ningún tipo de balanceo, simplemente la interface WAN2 entrará a funcionar si la WAN1 cae, ahora más adelante configuraremos las performance SLAs:

• Ahora vamos a crear una política en el firewall para darle acceso web a todos los usuarios de nuestra red interna LAN a través de la SD-WAN:

• Aquí tenemos la política creada:

• Ahora vamos a ver las Performance SLAs, accedemos a Network > SD-WAN > Performance SLAs y vemos que por defecto ya tenemos creadas algunas, con las Performance SLAs vamos a poder balancear por distintos criterios entre todas las interfaces miembros de la SD-WAN, estas performances SLAs que nos ha creado por defecto no tienen asignadas ninguna interface:

• En nuestro caso nos vamos a crear estas dos performances SLAs y las vamos a asociar a las dos interfaces WAN1 y WAN2 de nuestra SD-WAN:

• Como podemos ver, aquí las tenemos ya creadas y configuradas:

• Ahora si accedemos a nuestra zona SD-WAN, ya podemos ver que estamos realizando balanceo de carga, vemos que ya tenemos tráfico en ambas interfaces, no como antes, que todo estaba saliendo por la WAN1 y si fallaba ésta, entonces entraba en funcionamiento la WAN2:

• Realmente el balanceo de carga se realiza a través de las reglas de SD-WAN, y por defecto, ya trae una regla implícita, que realiza un balanceo del 50% en cada interface, nosotros nos podemos ir creando reglas más específicas y configurar balanceos por ejemplo a sitios webs más específicos a través de estas reglas, esta sería la regla implícita por defecto:

• Para Source IP, el tráfico se divide a partes iguales entre los miembros, y las sesiones que comienzan en la misma dirección de origen utilizan la misma ruta:

• Para Sessions, el tráfico se distribuye en función del número de sesiones que se conectan a través del miembro:

• Para Spillover, el miembro de mayor prioridad se utiliza hasta que el ancho de banda supera los umbrales de entrada y salida, el tráfico adicional se envía a través del siguiente miembro SD-WAN:

• Para Source-Destination IP, el tráfico se divide a partes iguales, las sesiones que empiezan en la misma dirección IP de origen y van a la misma dirección IP de destino utilizan la misma ruta:

• Para Volume, la carga de trabajo se distribuye en función del número de paquetes que pasan por el miembro:

• Y estos serían los algoritmos de balanceo de carga utilizados para la regla implícita por defecto, con origen en todos (all) y destinos en todos (all).
• Nosotros nos podemos crear reglas más específicas que se irán ubicando por encima de la regla implícita, teniendo así mayor prioridad, por ejemplo, nos vamos a crear una regla para el acceso a LinkedIn de los usuarios de nuestra LAN, para ello, accedemos a SD-WAN > SD-WAN Rule:

• Damos a Create new, dónde le asignamos un nombre, le indicamos el origen, que serán los equipos de nuestros usuarios, el destino que va a ser el servicio de internet LinkedIn-Web, le indicamos la estrategia del balanceo de carga a seguir, que será la que tenga mejor calidad con respecto al criterio de latencia utilizando uno de los performances SLAs que nos creamos anteriormente:

• Aquí tenemos la regla ya creada y operativa:

• A partir de aquí podemos ir ya configurando las reglas que nos vayan interesando y con los distintos balanceos de carga que nos vengan mejor.

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un web proxy transparente en un firewall Fortigate, un proxy transparente es una combinación de un proxy con NAT para que las conexiones se enruten dentro del proxy y el cliente no tenga que hacer ninguna configuración. En la mayoría de los casos en los que se emplea esta opción, el propio usuario desconoce que se esté utilizando un proxy.

• Para empezar, lo primero que vamos a realizar es habilitar en las características de nuestro firewall el Proxy Explícito, para ello accedemos a Sistema > Visibilidad de Característica > Funciones de seguridad y lo habilitamos:

• Lo siguiente que vamos a realizar será editar una de nuestras políticas de salida a Internet:

• En el Modo de inspección, lo configuraremos como Basado en Proxy, y aplicamos cambios:

• Una vez aplicado el cambio, vamos a editar la política por la CLI:

• Añadimos a la configuración set http-policy-redirect enable:

• Una vez introducido el comando, vemos que en la política ya nos aparece esta nueva opción:

• Habilitamos también en la regla, Inspección SSL > certificate-inspection:

• Ahora debemos acceder a Políticas y Objetos > Política de Proxy, como podemos ver, nos ha creado una política implícita de DENY, denegándonos el acceso a cualquier sitio web:

• Ahora desde cualquier equipo de nuestra LAN se le va a denegar el acceso hacia internet:

• Para habilitar la salida a Internet pasando por el web proxy, accedemos a Políticas y Objectos > Política de Proxy > Crear nuevo:

• Nos creamos esta regla como web transparente, dónde le indicamos a nuestra LAN, que le permitimos la conexión hacia Internet, a través del web proxy:

• Aquí la tenemos creada:

• Si accedemos a la misma web de antes, vemos que ya tenemos acceso:

• Ahora nos vamos a crear estos objetos de dirección, que son los que vamos a utilizar para denegar en las reglas las webs que nos interesen, Políticas y Objetos > Dirección > Crear nuevo > Dirección:

• Configuramos la categoría como Dirección de Proxy, le indicamos un Nombre, seleccionamos el patrón como Coincidencia de Expresión Regular de Host, y le ponemos el patrón que nos interese:

• Nos hemos creado estos objetos de dirección de proxy:

• Ahora nos vamos a crear esta regla para denegar la web o las webs que nos interesen, Políticas y Objectos > Política de Proxy > Crear nuevo:

• En esta regla denegamos a nuestra LAN el acceso a las webs indicadas:

• Como podemos ver, aquí la tenemos, y la ubicamos por encima de la regla de permitir todo el acceso a Internet:

• Ahora si intentamos acceder a cualquiera de estas webs nos va a indicar que no es posible, que tenemos el acceso denegado:

• Vemos que ya tenemos tráfico de denegación en nuestras reglas:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un servidor DHCP Relay en un firewall Fortigate, este DHCP relay va a escuchar las peticiones DHCP que se producen en la red, y las va a encaminar hacia un servidor DHCP que se encuentra en otra red para que éste las atienda, el servidor DHCP dará una respuesta que enviará hacia el DHCP relay configurado en nuestro Fortigate, y éste la trasladará al cliente que hizo la petición.

• Para empezar, vamos a ver que tenemos configurado nuestro servidor DHCP con el ámbito de red que queremos asignar a nuestros equipos clientes, y estas serían las distintas configuraciones del ámbito:

• Ahora en nuestro firewall fortigate vamos a acceder a Red > Interfaces y editaremos la red dónde vamos a configurar nuestro servidor DHCP relay:

• Sobre la edición de la interface de red, vamos a habilitar el servidor DHCP y en Avanzado seleccionamos el modo Relay, tipo Regular y ponemos la IP del servidor DHCP dónde hemos configurado el ámbito para esta red, en este caso, he puesto dos servidores DHCP ya que en mi infraestructura tengo montado un failover cluster para este servicio con balaceo de carga 50%-50%:

• Como podemos ver, ya lo tenemos configurado:

• Ahora accedemos a una máquina cliente de nuestra infraestructura, y como podemos ver, ya se le está sirviendo el direccionamiento IP y las opciones del ámbito que hemos configurado, todo ello, a través del DHCP relay configurado en el fortigate:

• En nuestra consola del servidor DHCP, podemos ver la concesión de direcciones para esta red:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo bloquear conexiones VPN SSL desde ciertas IPs públicas en un firewall Fortigate.

• En muchas ocasiones podemos ver en los logs de nuestros firewalls fortigate, que están intentando acceder a nuestra conexión VPN SSL desde IPs sospechosas, en esta captura podemos ver intentos de sesión fallidos desde una IP y está intentando probar con distintos usuarios:

• Para bloquear a esta IP pública, lo primero que voy a realizar será crearme un grupo de direcciones llamado blacklistipp, dónde iré añadiendo todas las IPs públicas sospechosas:

• Antes he creado los objetos de cada dirección IP pública, aquí muestro un ejemplo:

• Así nos quedaría:

• Para bloquear las conexiones VPN SSL a estas IPs públicas, accedemos a la consola de nuestro firewall y nos vamos a la configuración de la VPN SSL, con el comando config vpn ssl setting, una vez dentro de la configuración ejecutamos, set source-address «blacklistipp» y set source-address-negate enable, con el comando show podemos ver que la configuración se ha aplicado:

• Ahora, cuando un usuario intente conectarse desde una IP pública de la lista, la VPN SSL será rechazada:

• Es posible ver, que una de estas IPs públicas de la lista bloqueada está intentando conectarse, pero nuestro FortiGate no responde, para ello, ejecutamos el comando diagnose sniffer packet any «host 80.94.95.175 and port 10443» 4:

• Como podemos ver, si ejecutamos el comando, get vpn ssl monitor, se permitirá la conexión desde las IPs que no estén en la lista y se establecerán las conexiones:

• Otra forma de limitar el acceso, es irse a la Configuración de SSL_VPN > Restringir Acceso y Limitar acceso a hosts específicos, dónde configuro la restricción para el grupo de IPs públicas bloqueadas, aquí el problema es que la conexión no se rechaza en una primera instancia, es decir, nos va a dejar introducir las credenciales y una vez introducidas bloquea la conexión, con el método visto anteriormente por consola, la conexión se rechaza desde primera hora:

• Sobre este post realizado por mi compañero Héctor Herrero del blog Bujarra, podemos aplicar las listas dinámicas que nos está indicando sobre la configuración de la VPN, quedando de esta manera:

Saludos y espero que os sea de ayuda

En este post, vamos a ver cómo configurar el acceso administrativo a OPNSense vía web y SSH.

La topología que vamos a utilizar será esta:

• Primero, vamos a configurar el acceso administrativo a OPNSense vía web a través del puerto 30443, para ello, nos vamos a crear esta regla de entrada para el acceso interno a través de la VPN IPsec que ya tenemos configurada, Firewall > Rules > IPsec, le indicamos que desde un equipo de nuestra LAN on-premise vamos a poder acceder a la interface lan de opnsense en el puerto 30443:

• Si también queremos tener acceso, a través de la IP pública de OPNSense (interface WAN), accedemos a Firewall > Rules > WAN y nos creamos esta regla de entrada:

• Ahora desde System > Settings > Administration > Web GUI vamos a indicarle que el puerto de acceso es el 30443:

• En nuestro Fortigate on-premise hemos creado esta regla, para que el equipo de nuestra LAN on-premise tenga acceso al puerto 30443:

• Como podemos ver, ya tenemos acceso a la configuración web a través del puerto 30443:

• A continuación, vamos a configurar el acceso administrativo a OPNSense vía SSH a través del puerto 2490, para ello, nos vamos a crear esta regla de entrada para el acceso interno a través de la VPN IPsec que ya tenemos configurada, Firewall > Rules > IPsec, le indicamos que desde un equipo de nuestra LAN on-premise vamos a poder acceder a la interface lan de opnsense en el puerto 2490:

• Ahora desde System > Settings > Administration > Secure Shell vamos a indicarle que el puerto de acceso es el 2490:

• En nuestro Fortigate on-premise hemos creado esta regla, para que el equipo de nuestra LAN on-premise tenga acceso al puerto 2490:

• Como podemos ver, ya tenemos acceso a la configuración web a través del puerto 2490:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un servidor LDAP en OPNSense, así nos vamos a poder autenticar al firewall opnsense con usuarios del Active Directory y configurar vpn de acceso remoto con usuarios del Active Directory.

La topología que vamos a utilizar será esta:

• Accedemos a System > Access > Servers > +:

• Introducimos los datos necesarios para conectarnos a nuestro Active Directory:

• Como podemos ver, ya lo tenemos creado:

• Ahora sobre Firewall > Rules > IPsec debemos de crearnos esta regla de salida, para que OPNSense pueda acceder al puerto LDAP (389) de uno de nuestros controladores de dominio:

• Ahora, como nuestros controladores de dominio los tenemos en la parte on-premise, detrás de un fortigate, y como ya tenemos configurada la VPN IPSec site to site, debemos de configurar esta regla, para que OPNSense pueda acceder al puerto LDAP (389) de uno de nuestros controladores de dominio:

• Para comprobar que todo funciona correctamente y que OPNSense se comunica con nuestro servidor LDAP de Active DIrectory, accedemos a System > Access > Tester e introducimos las credenciales de uno de nuestros usuarios del dominio, damos clic a Test, y si todo está correctamente configurado, podemos ver que el usuario se autentica:

• Una vez que ya tenemos comunicación con nuestro Active Directory, vamos a configurar que podamos hacer logon en el OPNSense con uno de nuestros usuarios del dominio, para ello, lo primero que nos vamos a crear es un grupo de administradores de LDAP, accedemos a System > Access > Groups > +:

• Le indicamos un nombre y una descripción:

• Como podemos ver, aquí lo tenemos creado:

• Ahora debemos de editar los permisos de este grupo, y le asignamos todos los privilegios:

• Una vez creado el grupo, OPNSense requiere que todas las cuentas de usuario LDAP existan en la base de datos local, por lo que procederemos a crear la cuenta, System > Access > Users > +, esta cuenta la añadimos como miembro del grupo que hemos creado, la password no tiene porque ser la del usuario del dominio, podemos poner otra, lo que hace OPNSense es verificar primero la base de datos del LDAP y luego la base de datos local, por lo que si ponemos otra password a este usuario podemos acceder con las dos password (una del LDAP y la otra Local):

• Como podemos ver, aquí tenemos el usuario creado:

• A continuación, vamos a habilitar la autenticación LDAP, para ello, accedemos a System > Settings > Administration > Authentication > Server y seleccionamos la autenticación por LDAP Active Directory como primera opción, y como segunda opción seleccionamos la base de datos local, clic a Save:

• Ahora ya podemos acceder con las credenciales de nuestro usuario del dominio:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar una VPN site to site IPSEC entre un Fortigate on-premise y un OPNSense en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar será acceder a nuestro Fortigate on-premise, y sobre VPN > Túneles IPsec > Crear nuevo > IPsec Tunnel, empezaremos a crear el primer extremo de la VPN:

• En Configuración de VPN seleccionamos Personalizar y le indicamos un Nombre:

• En la parte de Red configuramos la IP estática que tenemos asignada al OPNSense de Azure y la interface de salida:

• En Autenticación le indicamos la Key compartida:

• Configuramos la fase 1:

• Configuramos la fase2:

• Como podemos ver, ya tenemos el primer extremo de la VPN configurado, el de la parte on-premise:

• Ahora vamos a crear las políticas:

• Accedemos a Políticas y objetos> Política IPv4 > Crear nuevo:

• Creamos una política para la conexión de sitio a sitio que permita el tráfico saliente:

• Creamos otra política para la conexión de sitio a sitio que permita el tráfico entrante:

• Aquí podemos ver las políticas creadas:

• Ahora creamos la ruta estática hacia Azure:

• Lo segundo que vamos a realizar será acceder a nuestro OPNSense en Azure, y sobre Firewall > WAN > +, nos crearemos tres reglas de firewall para permitir el tráfico IPSEC a la interfaz WAN:

• Regla para IPSec ESP:

• Regla para IPSec ISAKMP puerto 500:

• Regla para IPSec NAT-T puerto 4500:

• Como podemos ver aquí tenemos las tres reglas creadas en la interface WAN:

• Ahora vamos a configurar la fase 1 de la VPN site to site, para ello, accedemos a VPN > IPSec > Connections > Tunnel Settings (legacy) > +:

• Como podemos ver, ya tenemos la fase 1 creada, habilitamos IPSec y aplicamos los cambios:

• Ahora vamos a configurar la fase 2 de la VPN site to site, para ello, accedemos a VPN > IPSec > Connections > Tunnel Settings (legacy) > +:

• Aplicamos los cambios:

• Como podemos ver, ya tenemos la fase 2 de la VPN site to site configurada:

• Para terminar, vamos a crear dos políticas, una de entrada y otra de salida para comunicar las dos subredes que tenemos, una en Azure y otra On-premise, para ello, accedemos a Firewall > Rules > IPSec > +:

• Regla de entrada:

• Regla de salida:

• Aquí vemos las dos reglas creadas:

• A continuación, sobre Firewall > Rules > LAN vamos a crear esta regla para permitir el tráfico entre la subred de Azure y la subred on-premise:

• Como podemos ver, ya tenemos el túnel IPSEC levantado.
• Fortigate On-premise:

• OPNSense Azure:

• Para verificar que todo funciona correctamente vamos a realizar un ping desde una máquina on-premise a una máquina en Azure y viceversa:

Saludos y espero que os sea de ayuda

En este post, vamos a ver cómo configurar las categorías y alias, estos alias serán los que vamos a aplicar posteriormente en las reglas del firewall.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a configurar serán las categorías, para ello, accedemos a Firewall > Categories > + y vamos añadiendo las que nos interesen:

• Por ejemplo, en este caso, nos hemos creado una llamada Web Access:

• Aquí vemos todas las que nos hemos creado:

• Una vez que nos hemos creado las categorías, podemos proceder a crear los Alias, vamos a mostrar ejemplos de alias para un solo puerto, dos puertos, un rango de puertos, host, grupo de hosts y red, para ello, accedemos a Firewall > Aliases > +:

• Empezamos por mostrar un ejemplo de un solo puerto, por ejemplo, para el servicio SSH:

• Ejemplo con dos puertos, SNMP:

• Ejemplo con un rango de puertos:

• Ejemplo con grupo rango de puertos, Windows Active Directory:

• Ejemplo con un solo host:

• Ejemplo con un grupo de hosts:

• Ejemplo para una red:

• Como resumen, nos quedaría algo parecido a esto:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo realizar la configuración inicial y avanzada en nuestro firewall OPNSense en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar será cambiar la password de root del sistema, para ello accedemos a Lobby > Password y procedemos a cambiarla:

• Esta password también la podemos cambiar desde System > Access > Users > root:

• Sobre System > Settings > General configuramos el nombre del host, dominio, zona horaria y los servidores DNS:

• Sobre Services > Network Time > General configuramos los servidores NTP:

• Las interfaces LAN y WAN las dejamos tal y como están, configuradas por DHCP, ya que en la propia máquina de Azure las hemos configurado con una IP estática:

• Sobre Firewall > Aliases vamos a configurar los distintos objetos que iremos utilizando en las reglas de filtrado del firewall OPNSense:

• Sobre Type podemos ver los distintos objetos que nos podemos ir creando, Host(s), Network(s), Port(s), etc… :

• Estos son los que nos hemos creado en un principio, esta lista irá en aumento a medida que vayamos necesitando objetos en nuestras reglas de filtrado:

• Sobre Firewall > Rules > WAN nos hemos creado esta regla de entrada (IN) para acceder al portal de configuración de OPNSense a través de otro puerto distinto al 443:

• Para habilitarlo, debemos ir a System > Settings > Administration y sobre TCP port configurar el puerto:

• Como vemos, ya podemos acceder a la configuración de OPNSense a través del puerto que hemos configurado:

• La regla que había configurada por defecto al puerto 443, la podemos deshabilitar:

• A continuación, vamos a configurar esta regla que permita todo el tráfico entre las máquinas de la misma subred dónde vamos a ubicar las máquinas virtuales de Azure, para ello accedemos a Firewall > Rules > LAN:

• Ahora vamos a habilitar la salida a Internet para las máquinas que nos montemos en Azure, para ello, accedemos a Firewall > NAT > Outbound seleccionamos Hybrid outbound NAT rule generation y nos creamos esta regla para en NATEO:

• Sobre Firewall > Rules > LAN nos debemos de crear esta regla de entrada (IN), esta regla va a permitir el tráfico saliente a Internet desde nuestra subred para máquinas virtuales en Azure, sólo permite el tráfico a Internet y no a otras IPs privadas, de ahí que marquemos el invert:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo desplegar y configurar una tabla de rutas UDR (User Definition Routes) en Azure.

La topología que vamos a utilizar será esta:

• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar la subred LAN que configuramos anteriormente, esta subred es dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya la tenemos asociada:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas > Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Una vez configurada la tabla de rutas, accedemos a nuestro OPNSense en Azure, y nos vamos a crear estas dos rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del OPNSense lo envíe por la interface WAN al gateway de la subred Untrusted, y la segunda ruta son para servicios internos de Azure, para que lo envíe por la interface LAN al gateway de la subred Trusted:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo desplegar un firewall OPNSense en Azure con dos interfaces de red.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar es acceder a este link de dmauser, aquí vamos a encontrar un desarrollo para desplegar un firewall OPNSense sobre FreeBSD con dos NICs:

• Se nos abrirá esta plantilla para el despliegue de OPNSense, sobre Deployment Scenarios le indicamos la suscripción, el grupo de recursos, la región y muy importante OPNSense Scenario que le indicamos TwoNics:

• Sobre Virtual Machine Settings le indicamos el nombre y tamaño de máquina, la URL para la descarga del script, la versión de OPNSense y la versión del agente de Azure:

• Para el despliegue y la configuración de la red virtual en Azure, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales (ésta última la configuraremos a posteriori de la plantilla de despliegue):
• Red virtual: opnsense-vnet 192.168.128.0/18
• Subred Externa: Untrusted-Subnet 192.168.191.0/27
• Subred Interna: Trusted-Subnet 192.168.191.32/27
• LAN Azure: SubnetLAN-192_168_128_0-24

• Sobre Virtual Network Settings estas serían las configuraciones para nuestra infraestructura:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, comenzamos a Crear todos los recursos de la plantilla OPNSense deployment:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente, podemos ver, los distintos recursos que ha creado el despliegue de esta plantilla:

• Ahora accedemos al grupo de recursos y clicamos sobre la máquina virtual:

• En la máquina virtual accedemos a Redes y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN de OPNSense que tiene una IP privada y otra pública, y la otra es la interface LAN que solo tiene una IP privada:

• Debemos de configurar las IPs privadas como estáticas, tanto la WAN cono la LAN:

• Para acceder al firewall accedemos a través de su IP pública, https://PublicIP, las credenciales por defecto son root/opnsense, en un post posterior veremos cómo se cambia:

• Este sería el Dashboard principal de OPNsense, en los próximos post realizaremos las configuraciones básicas y avanzadas:

• Como comentamos anteriormente, vamos a configurar la red local de Azure dónde se conectarán nuestras máquinas virtuales, LAN Azure: SubnetLAN-192_168_128_0-24:

Saludos y espero que os resulte de ayuda

En estos posts vamos a ver cómo desplegar y configurar un firewall OPNSense en Azure.

La topología que vamos a utilizar será esta:

Este post lo vamos a dividir en:

• Despliegue Firewall OPNSense en Azure
• Desplegar y configurar tabla de rutas UDR en Azure
• Configuración inicial y avanzada OPNSense
• Configurar Categorías y Alias
• VPN site to site IPSEC entre Fortigate on-premise y OPNSense Azure
• Configurar servidor LDAP en OPNSense
• Acceso administración Web y SSH OPNSense

Saludos.

En este post vamos a ver cómo configurar una VPN site to site IPSEC entre Fortigate on-premise y Fortigate Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar será acceder a nuestro Fortigate on-premise, y sobre VPN > Túneles IPsec > Crear nuevo > IPsec Tunnel, empezaremos a crear el primer extremo de la VPN:

• En Configuración de VPN seleccionamos Personalizar y le indicamos un Nombre:

• En la parte de Red configuramos la IP estática que tenemos asignada al Fortigate de Azure y la interface de salida:

• En Autenticación le indicamos la Key compartida:

• Configuramos la fase 1:

• Configuramos la fase2:

• Como podemos ver ya tenemos el primer extremo de la VPN configurado, el de la parte on-premise:

• Ahora vamos a crear las políticas:

• Accedemos a Políticas y objetos> Política IPv4 > Crear nuevo:

• Creamos una política para la conexión de sitio a sitio que permita el tráfico saliente:

• Creamos otra política para la conexión de sitio a sitio que permita el tráfico entrante:

• Aquí podemos ver las políticas creadas:

• Ahora creamos la ruta estática hacia Azure:

• Lo segundo que vamos a realizar será acceder a nuestro Fortigate en Azure, y sobre VPN > Túneles IPsec > Crear nuevo > IPsec Tunnel, empezaremos a crear el segundo extremo de la VPN:

• En Configuración de VPN seleccionamos Personalizar y le indicamos un Nombre:

• En la parte de Red configuramos la IP estática que tenemos asignada al Fortigate on-premise y la interface de salida:

• En Autenticación le indicamos la Key compartida:

• Configuramos la fase 1:

• Configuramos la fase2:

• Como podemos ver ya tenemos el segundo extremo de la VPN configurado, el de la parte de Azure:

• Ahora vamos a crear las políticas:

• Accedemos a Políticas y objetos> Firewall Policy> Crear nuevo:

• Creamos una política para la conexión de sitio a sitio que permita el tráfico saliente:

• Creamos otra política para la conexión de sitio a sitio que permita el tráfico entrante:

• Aquí podemos ver las políticas creadas:

• Ahora creamos la ruta estática hacia nuestro entorno on-premise:

• Como podemos ver, ya tenemos el túnel IPSEC levantado:

• Para verificar que todo funciona correctamente vamos a realizar un ping desde una máquina on-premise a una máquina en Azure y viceversa:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo desplegar y configurar una tabla de rutas en Azure.

La topología que vamos a utilizar será esta:

• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Como podemos ver, comienza a implementar la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar la subred LAN que configuramos anteriormente, esta subred es dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya la tenemos asociada:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas a Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Una vez configurada la tabla de rutas, accedemos a nuestro Fortigate en Azure, y nos vamos a crear estas tres rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del Forti lo envíe por la interface WAN al gateway de la subred external, la segunda ruta es para que todo lo configurado en el espacio de direcciones de la red virtual lo envíe por la interface LAN al gateway de la subred internal, y la tercera ruta son para servicios internos de Azure para que lo envíe por la interface LAN al gateway de la subred internal:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo desplegar un firewall Fortigate en Azure a través del Marketplace.

La topología que vamos a utilizar será esta:

• Accedemos al Marketplace, buscamos por fortigate y seleccionamos la opción Fortinet FortiGate Next-Generation Firewall > Crear > Single VM:

• En el despliegue del firewall sobre Básico le indicamos el grupo de recursos, la región, las credenciales de usuario, el prefijo del nombre, tipo de licencia y la versión de la imagen del Fortigate:

• Sobre Instance le indicamos el tamaño de máquina, le adjuntamos la licencia y le indicamos el nombre:

• Sobre Networking le indicamos la red virtual que vamos a utilizar y las subredes del firewall que ya configuramos en un post anterior:

• Sobre Public IP configuramos una IP pública básica y estática:

• Sobre Advanced no tocamos nada ya que no tenemos configurado FortiManager:

• Nos muestra un resumen de todas las configuraciones realizadas, comenzamos a crear la máquina:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente:

• Ahora accedemos al grupo de recursos y clicamos sobre la máquina virtual:

• En la máquina virtual accedemos a Redes y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN del Fortigate que tiene una IP privada y otra pública, y la otra es la interface LAN que solo tiene una IP privada:

• Para acceder al firewall accedemos a través de su IP pública:

• Le aplicamos un alias a sus interfaces como WAN y LAN:

• Y así nos quedaría:

• También configuramos el acceso a nuestro Fortigate para que lo haga a través del puerto 30443:

• Como podemos ver, ahora tenemos que acceder a través del puerto configurado:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo desplegar y configurar una red virtual en Azure para firewall Fortigate.

La topología que vamos a utilizar será esta:

• Empezaremos con el despliegue y la configuración de la red virtual en Azure, para ello, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales:
• Red virtual: rgs-firewall-vnet 192.168.128.0/18
• Subred Externa: ExternalSubnetFortigate 192.168.191.0/27
• Subred Interna: InternalSubnetFortigate 192.168.191.32/27
• Subred Protected: ProtectedSubnetFortigate 192.168.191.64/27
• LAN Azure: Subvnet_rgs_192.168.130.0-24_LAN 192.168.130.0/24

• Todos los recursos creados los vamos a ubicar dentro de este grupo de recursos:

• Nos creamos la red virtual, dónde en Datos básicos le indicamos, el grupo de recursos y el nombre:

• En Seguridad lo dejamos por defecto:

• En Direcciones IP configuramos el espacio de direcciones y las subredes que vamos a utilizar:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la red virtual:

• Como podemos ver, el recurso de red virtual se ha creado correctamente, podemos ir al recurso:

• Dónde podemos ver el Espacio de direcciones configurado y las Subredes que vamos a utilizar para desplegar el firewall Fortigate y para ubicar nuestras máquinas virtuales:

Saludos y espero que os sea de ayuda