miércoles, 7 de octubre de 2026

 ¿Tener dos firewalls significa tener una red en alta disponibilidad?


No necesariamente.

Una empresa puede instalar dos SonicWall y seguir teniendo otros puntos únicos de falla.

Para entenderlo debemos separar las diferentes capas.

Internet

Podemos contratar dos proveedores.

Eso protege frente a determinadas fallas del ISP.

Firewall

Si ambos enlaces llegan a un solo equipo, la falla del firewall puede detener ambas conexiones.

Aquí entra SonicWall High Availability.

En un par HA tenemos dos appliances idénticos.

Uno actúa normalmente como Active.

El otro permanece Standby.

Si el activo presenta una condición de falla, el secundario puede asumir sus responsabilidades.

Stateless vs Stateful

Esta diferencia es importante.

En Active/Standby sin sincronización stateful, el segundo firewall puede tomar el control, pero determinadas conexiones existentes necesitan establecerse nuevamente.

En Stateful HA se sincroniza información dinámica entre ambos equipos.

Esto puede mejorar la continuidad de VPN, sesiones y aplicaciones persistentes.

Pero todavía falta revisar el switch

Imaginemos:

Dos ISP

Dos SonicWall

Un solo switch core

La falla de ese switch puede interrumpir toda la operación.

El firewall ya no es el único punto de falla, pero la infraestructura completa todavía no es redundante.

También debemos revisar energía

Los dos appliances deberían integrarse adecuadamente con la estrategia de UPS y alimentación.

Conectar ambos equipos a una sola fuente que puede fallar puede reducir el valor de la redundancia.

¿Qué es HA Monitoring?

SonicWall puede observar tanto interfaces físicas como conectividad lógica.

Esto resulta importante porque una interfaz puede continuar eléctricamente activa aunque exista un problema real en la red conectada.

¿Qué es Active/Active DPI?

No debe confundirse con dos firewalls balanceando completamente todo el tráfico.

En esta modalidad el equipo secundario puede colaborar con determinadas tareas de Deep Packet Inspection mientras el principal sigue manejando el forwarding y otros procesos.

Puede resultar interesante en entornos con mucha inspección SSL, IPS y Application Control.

La conclusión:

Alta disponibilidad no significa duplicar equipos.

Significa identificar qué puede fallar y construir caminos alternativos adecuados.

Guía completa:

https://sistro.net/sonicwall-high-availability-active-standby-stateful-ha




 Cómo diseñar correctamente la red de un cluster Proxmox

Cuando se diseña una infraestructura de virtualización normalmente hablamos primero de CPU, RAM y almacenamiento.

Pero existe otra capa que puede convertirse en el principal cuello de botella:

la red.

En Proxmox VE podemos tener simultáneamente tráfico de:

administración
máquinas virtuales
Corosync
storage
migración
backup

Si todos utilizan la misma interfaz y esa conexión se satura, la plataforma completa puede verse afectada.

Linux Bridge

Proxmox utiliza Linux Bridge como uno de sus componentes fundamentales.

Una interfaz como vmbr0 puede verse conceptualmente como un switch virtual.

Las máquinas virtuales se conectan al bridge y éste se conecta posteriormente a una interfaz física o a un bond.

VLAN

Un bridge puede configurarse como VLAN-aware.

Esto permite utilizar un trunk físico y transportar varias redes a través del mismo enlace.

Por ejemplo:

VLAN 10 → Management
VLAN 20 → Servidores
VLAN 30 → Aplicaciones
VLAN 40 → DMZ

Cada VM puede recibir la etiqueta correspondiente.

Bonding

También podemos agrupar varias interfaces físicas.

Una opción sencilla es Active-Backup.

Una NIC trabaja y otra queda preparada para tomar el tráfico en caso de falla.

Otra posibilidad es LACP mediante 802.3ad.

Esto puede proporcionar redundancia y mayor capacidad agregada cuando también está correctamente configurado en el switch.

Pero existe una confusión frecuente:

2 × 10 GbE no significa necesariamente que una única transferencia utilice 20 Gbps.

LACP distribuye diferentes flujos entre interfaces.

Corosync

El tráfico de cluster necesita especial cuidado.

Corosync no requiere enormes cantidades de ancho de banda.

Necesita una comunicación estable y con baja latencia.

Por eso puede ser mejor dedicar una red relativamente sencilla a Corosync que compartirla con almacenamiento o backup capaces de saturar enlaces de alta velocidad.

Storage

Ceph, NFS, iSCSI y otros sistemas de almacenamiento pueden generar mucho tráfico.

En plataformas con SSD o NVMe, la red incluso puede convertirse en el límite antes que los propios discos.

Redundancia

Dos NIC no garantizan alta disponibilidad.

Si las dos llegan al mismo switch seguimos dependiendo de un único equipo.

La arquitectura correcta debe preguntar:

¿Qué ocurre si falla una NIC?

¿Qué ocurre si falla un cable?

¿Qué ocurre si falla un switch?

Ese análisis diferencia una red que simplemente funciona de una red diseñada para producción.

Guía completa:

https://sistro.net/proxmox-networking-bridge-vlan-bonding-lacp



martes, 6 de octubre de 2026

FortiGate cambia SSL VPN: qué revisar antes de actualizar FortiOS 7.6.3

Actualizar un firewall sin revisar los cambios de funcionalidades puede provocar una interrupción innecesaria.

Uno de los cambios más importantes de Fortinet afecta directamente al acceso remoto.

A partir de FortiOS 7.6.3, SSL VPN tunnel mode deja de estar disponible.

Esto resulta especialmente relevante para empresas que utilizan FortiClient para que empleados, administradores o proveedores accedan a recursos internos.

La migración recomendada se orienta hacia IPsec VPN.

Pero no basta con actualizar FortiOS y esperar que la configuración existente se transforme automáticamente.

Antes debemos conocer qué tenemos actualmente.

Usuarios

¿Cuántas personas se conectan?

Autenticación

¿Utilizamos Active Directory, RADIUS, SAML o usuarios locales?

MFA

¿Existe segundo factor?

Split Tunnel

¿Solamente enviamos redes corporativas por la VPN?

Full Tunnel

¿Todo el tráfico pasa por el corporativo?

Aplicaciones

¿ERP, RDP, archivos, DNS, bases de datos?

Después podemos construir la nueva VPN IPsec.

Una capacidad especialmente interesante es IPsec sobre TCP.

Esto permite trabajar incluso en determinados entornos donde UDP tradicional puede estar bloqueado.

Fortinet contempla incluso TCP 443 para estos escenarios.

La estrategia que recomendamos es:

1. Inventariar

2. Configurar IPsec

3. Crear un grupo piloto

4. Probar desde diferentes redes

5. Migrar usuarios

6. Validar aplicaciones

7. Actualizar FortiOS

También es una buena oportunidad para preguntarse si todos los usuarios realmente necesitan una VPN completa.

Algunos pueden requerir solamente determinadas aplicaciones.

En esos casos tecnologías como ZTNA pueden formar parte de la estrategia.

La guía técnica completa está disponible en:

https://sistro.net/fortigate-ssl-vpn-ipsec-fortios-7-6-3