Cuando la gente piensa en IPsec, piensa en la encriptación de datos, pero también se puede utilizar para dejar caer paquetes o permitirlos sin ninguna encriptación. Puede hacerlo basándose en la dirección IP de origen y destino y en los números de puerto. Que es exactamente lo que hace un cortafuegos; así que puedes usar la característica IPsec de VOS como un cortafuegos.
Por ejemplo, digamos que tiene una aplicación de servicio de documentos internos que escucha en *.12345, es decir, escucha en el puerto 12345 y aceptará una conexión desde cualquier interfaz del módulo. Se acaba de añadir una nueva interfaz al módulo que se conecta a la red de un proveedor. Nadie de esa red debe conectarse al servicio de documentos. Lo ideal es que haya un cortafuegos en la red entre el módulo y la red del proveedor que bloquee el puerto 12345, pero el principio de "defensa a fondo" dice que un cortafuegos basado en la red Y el host es mejor que sólo un cortafuegos de red.
Hay varias formas de configurar IPsec para que deje caer las conexiones de la red del proveedor. La forma más sencilla es dejar caer cualquier conexión al puerto 12345 con una dirección IP de destino que corresponda a la nueva interfaz. Asumiendo que la nueva interfaz tiene una dirección IP de 172.16.1.1 la política IPsec sería como
{dirección 172.16.1.1 ulp tcp dport 12345 dir in} drop {}
Las políticas IPsec se añaden con el comando ipsec_policy_admin. El archivo de configuración por defecto es >system>stcp>ipsec.conf, pero se puede especificar cualquier archivo. Para que esto funcione, el módulo no debe estar reenviando paquetes, de lo contrario se reenviará una petición de conexión a otra de las interfaces del módulo que se reciba en la interfaz 172.16.1.1. Como el destino no es 172.16.1.1 IPsec permitirá la conexión. Es una buena idea desactivar el reenvío a menos que sepas que realmente necesitas usarlo. Desactiva el reenvío con el comando IP_forwarding; sí, la IP es mayúscula.
Si no se ha añadido una nueva interfaz y tanto sus usuarios internos como su proveedor van a utilizar la misma interfaz, debe basar la política en la dirección de origen, no en la de destino. Si suponemos que la red del proveedor es 192.168.1.0/24, la política tendrá el siguiente aspecto
{dirección 192.168.1.0/24 ulp tcp dport 12345 dir in} drop {}
Esto, por supuesto, sigue permitiendo a los hosts de la red del proveedor conectarse a otros servicios del módulo. Puede restringir los proveedores a un solo servicio, digamos el que escucha en el puerto 24680 con las siguientes políticas
{saddr 192.168.1.0/24 ulp tcp dport 24680 dir in} bypass {}
{dirección 192.168.1.0/24 ulp tcp dir in} drop {}
Si el servicio de documentos sólo aloja los documentos de un departamento, puede configurar una política que permita las conexiones al puerto 12345 sólo desde la subred de ese departamento, digamos 10.1.1.0/28 con las políticas
{saddr 10.1.1.0/28 ulp tcp dport 12345 dir in} bypass {}
{saddr 0.0.0/0 ulp tcp dport 12345 dir in} drop {}
El orden de las políticas es importante, si inviertes el orden nadie podrá conectarse al puerto 12345.
Si su CIO requiere que él también tenga acceso a los documentos, puede añadir una política para la dirección de la estación de trabajo del CIO
{dirección 10.1.1.0/28 ulp tcp dport 12345 dir in} bypass {}
{dirección 10.7.7.7 ulp tcp dport 12345 dir in} bypass {}
{saddr 0.0.0/0 ulp tcp dport 12345 dir in} drop {}
Mientras experimentas con IPsec asegúrate siempre de que tienes una política en el lugar que te permitirá una conexión, las políticas de IPsec se actúan tan pronto como se añaden, no necesitas reiniciar nada así que una política escrita incorrectamente podría desconectarte del módulo. Por ejemplo, asumiendo que la dirección IP de tu estación de trabajo es 10.1.100.50, siempre pondría la siguiente política primero en mi archivo de políticas
{saddr 10.1.100.50 ulp tcp dir in} bypass {}