Aunque hay otras soluciones para la implementación de un firewall con capacidades de router en el mundillo del software libre y que además sea código abierto, hay pocos que presentan el HA de clase empresarial como opción. Debido a que pfSense es una de las soluciones más expandidas en nuestro territorio se presenta el siguiente tutorial para configurar su HA.
La High Availability (HA) o alta disponibilidad en pfSense se hace con la idea de tener un hardware de respaldo, ya que en caso de el firewall primario o alguno de sus enlaces falle pues el firewall secundario asume el role del primario, eliminando en nuestras empresas a los firewalls como punto único de fallo en la red.
Vamos a lo interesante entonces?
1- Laboratorio virtual
Para comprobar la configuración se realizará el siguiente laboratorio con el software GNS3:
Como se aprecia tenemos un firewall principal, que interpretará el role de Primario: fw-romeo (el cual para ser diferenciado tendrá un fondo negro) y un secundario que hará el role de Backup: fw-julieta (para diferenciarlo tendrá un fondo negro) (¿no es romántico?). Ambos corriendo pfSense 2.5.2 (ambas VMs de pfSense deben ser exactamente iguales, se recomienda clonarlas una vez se instale la primera) con 3 interfaces de red con las siguientes configuraciones:
- em0: Red WAN 192.168.0.0/29
- em1: Red HASYNC 10.10.10.1
- em2: Red LAN 10.7.5.0/24
2- Configuraciones de red
Configuración de red fw-romeo:
- em0: WAN: 192.168.0.1/29
- em1: HASYNC:10.10.1/24
- em2: LAN:7.5.1/24
Configuración de red fw-julieta:
- em0: WAN: 192.168.0.2/29
- em1: HASYNC:10.10.2/24
- em2: LAN:7.5.2/24
En el laboratorio se tiene un router, que representa nuestro ISP con el IP 192.168.0.101. Y también se tiene una PC corriendo Linux Puppy que representa a cualquier PC de nuestra LAN que tengo acceso a la red de gestión de los firewalls, en este caso con IP 10.7.5.100.
El objetivo del laboratorio es comprobar que en caso de que fw-romeo presente dificultades (pérdida de un enlace, sistema apagado por problemas de hardware…) fw-julieta asuma el role de hombre de la casa…
NOTA: Este tutorial no abarca las configuraciones iniciales en pfSense. Se supone que ya fueron configuradas las direcciones IP de cada interfaz de red, así como las puertas de enlaces y la ruta predeterminada o rutas estáticas. También debe haberse creado una regla que permita todo le tráfico de entrada en la interfaz LAN y WAN, sólo para las pruebas del laboratorio. |
3- Reglas para HASYNC
Se crean las reglas recomendadas por pfSense en la interfaz de sincronización. A continuación, en fw1-romeo (para llegar: Firewall -> Rules -> HASYNC):
A continuación, configuración en fw1-julieta (para llegar: Firewall -> Rules -> HASYNC):
4- Creación de un usuario para la sincronización
Ahora necesitamos crear un usuario que se va a encargar únicamente de la sincronización. En fw-romeo creamos el usuario “hasync” sin agregarle ninguna otra configuración, más allá de la por defecto. En el “fw1-primario” (para llegar: System -> Users manager-> Users):
Luego de creado necesitamos agregarle el permiso de sincronización, así que lo editamos y le agregamos el permiso System – HA node sync:
Haremos exactamente igual en fw-julieta:
(¡¡¡Recuerde la contraseña!!!)
5- Sincronización para la Alta Disponibilidad:
En el fw-romeo, se habilita la sincronización de estados, se especifica la interfaz de red por la cual se sincronizarán romeo y julieta, y se especifica la dirección IP de julieta (para llegar: System -> High Avail. Sync):
En el fw-julieta se realizarán similares configuraciones, solo que a la hora de ponerle el PeerIP tener en cuenta de poner el IP de fw-romeo:
La siguiente sección de configuración para alta disponibilidad, sólo se hace en el “master” (fw-romeo). En ella se especifican nuevamente la dirección IP del cortafuego secundario (fw-julieta), así como el usuario y la contraseña que se usará para la sincronización (el usuario que previamente creamos: “hasync”). Se marcan todas las casillas disponibles, como opciones de sincronización:
Al dar Save se puede comprobar inmediatamente en los logs del sistema si se realizó con éxito la configuración (para llegar: Status –> System Logs):
Para comprobar que la sincronización haya sido exitosa, se puede crear una regla de ejemplo en el fw-romeo y la misma deberá aparecer instantáneamente en fw-julieta. A partir de este momento ambos cortafuegos se comportan como uno solo y se configurarán siempre a partir del primario, ya que los cambios en julieta no se replicarán en romeo.
Regla creada en fw-romeo solo para comprobar:
Regla replicada en fw-julieta:
Pequeña introducción teórica Common Address Redundancy Protocol (CARP) fue creado por los desarrolladores de OpenBSD como una solución de redundancia abierta y gratuita para compartir direcciones IP entre un grupo de dispositivos de red. Ya existían soluciones similares, principalmente el estándar IETF para el Protocolo de redundancia de enrutador virtual (VRRP). Sin embargo, Cisco afirma que VRRP está cubierto por su patente sobre su Hot Standby Router Protocol (HSRP), y les dijo (¿o amenazó con?) a los desarrolladores de OpenBSD que haría cumplir su patente. Por lo tanto, los desarrolladores de OpenBSD crearon un nuevo protocolo abierto y gratuito para lograr esencialmente el mismo resultado sin infringir la patente de Cisco. CARP estuvo disponible en octubre de 2003 en OpenBSD, y más tarde también se agregó a FreeBSD. Una dirección IP virtual (VIP) de tipo CARP se comparte entre los nodos de un clúster. Un nodo es maestro y recibe tráfico para la dirección IP, y los otros nodos mantienen el estado de respaldo y monitorean los latidos (beats) para ver si necesitan asumir el rol de maestro si el maestro anterior falla. Dado que solo un miembro del clúster a la vez usa la dirección IP, no hay conflicto de direcciones IP para los VIP de CARP. Para que la conmutación por error funcione correctamente, es importante que el tráfico entrante que llega al clúster, como el tráfico ascendente enrutado, VPN, NAT, puerta de enlace de cliente local, solicitudes de DNS, etc., se envíe a un CARP VIP y para el tráfico saliente, como NAT saliente que se enviará desde un CARP VIP. Si el tráfico se dirige a un nodo directamente y no a un CARP VIP, otros nodos no captarán ese tráfico. CARP funciona de manera similar a VRRP y HSRP, e incluso puede entrar en conflicto en algunos casos. Los latidos se envían en cada interfaz que contiene un CARP VIP, un latido por VIP por interfaz. En los valores predeterminados de skew y base, un VIP envía latidos aproximadamente una vez por segundo. El skew determina qué nodo es el maestro en un momento dado. El nodo que transmita latidos más rápido asume el rol de maestro. Un valor de skew más alto hace que los latidos se transmitan con más retraso, por lo que un nodo con un skew más bajo será el maestro a menos que una red u otro problema provoque que los latidos se retrasen o se pierdan. Un clúster de alta disponibilidad que usa CARP necesita tres direcciones IP en cada subred junto con una subred separada sin usar para la interfaz de sincronización. Para las WAN, esto significa que se requiere una subred /29 o más grande para una configuración óptima. Cada nodo utiliza una dirección IP, más una dirección VIP CARP compartida para la conmutación por error. La interfaz de sincronización solo requiere una dirección IP por nodo. |
La idea básica es que ambos firewalls compartan una misma IP (virtual), así que el esquema de nuestra red se modifica un tanto:
Se crean las direcciones IP virtuales en fw-romeo para el protocolo CARP (para llegar: Firewall -> Virtual IPs):
Especificamos la dirección IP virtual para la WAN (en este ejemplo utilizaremos la 192.168.0.5), por la cual responderán ambos cortafuegos. Se recomienda usar como contraseña la misma del usuario de sincronización, aunque se puede utilizar otra, solo se tiene que tener en cuenta que coincidan en ambos firewalls. El “VHID Group” se recomienda que sea el valor del último octeto de la dirección IP virtual. En el apartado de Advertising Frequency se deja en 1 en ambos firewalls, pero en el apartado de Skew en el firewall primario (fw-romeo) tiene que tener un valor de 0, mientras que en el secundario (fw-julieta) tiene que tener un valor de 100 o mayor, de lo contrario la redundancia va a presentar problemas (¡¡¡esto se realiza automáticamente!!!).
Configuración de la WAN CARP VIP:
Configuración de la LAN CARP VIP:
Quedando la configuración en el apartado de Firewall -> Virtual IPs:
En el fw-julieta deberán de haberse ejecutado los cambios mediante la sincronización, automáticamente:
Si se editan las VIP CARP en el secundario, se podrá observar que la única variación respecto al primario es en el “skew”, que por defecto lo pone en 100 para el secundario. Viendo el estado del CARP, se puede determinar cuándo uno está en estado “master” o “backup”, (para llegar: Status > CARP (failover)):
Status > CARP (failover) de fw-romeo en operación normal:
Status > CARP (failover) de fw-julieta en operación normal:
7- Comprobacion de la HA en el laboratorio virtual
Si desconectamos el cable de red de la interfaz WAN del fw-romeo, fw-julieta debe de asumir el role de Master:
Status > CARP (failover) de fw-romeo cuando su enlace WAN presenta problemas:Status > CARP (failover) de fw-julieta cuando su enlace WAN presenta problemas:
Durante este proceso de transición de estados, solo se perdieron tres paquetes (secuencias 82, 83 y 84 del PING y luego se reanudó en la secuencia 85) en un ping continuo desde la PC Puppy-1 hasta el router del ISP.
Lo mismo sucedería si la interfaz LAN presenta problemas, pero no podríamos ver el estado de aquel firewall que perdiera su interfaz LAN pues en nuestro caso solo se gestiona el mismo desde esa interfaz, solo lo notaríamos si se cae la interfaz LAN de primario (fw-romeo) y el secundario (fw-julieta) asume el role de Master.
Si ambos firewalls presentan problemas de conectividad con el ISP, ambos asumen el role de master reanudando su role usual una vez alguno de los enlaces retorne.
8- Listo!!!
Y es todo! Ya tienen su firewall de backup por si el master se rompe!!!
Autores:
- Frank Morales
- Franco Díaz
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Muy buen material me encuentro en proceso de aplicarlo en este instante muchas gracias.