Sophos Firewall Configurar zonas e interfaces

Las zonas y las interfaces se encuentran entre los fundamentos más importantes de un Sophos Firewall. Si las planifica cuidadosamente, facilitará mucho las reglas de firewall, NAT, VPN, protección web y resolución de problemas posteriores. Si los junta demasiado rápido, a menudo se crea un entorno en el que las reglas se vuelven confusas o los servicios de administración son accesibles en los lugares equivocados.

Una Zona es un grupo de seguridad lógico. Una Interfaz es una conexión física o virtual, por ejemplo Port1, una VLAN, un Puente, un LAG, un Alias, una interfaz RED o una interfaz XFRM para VPN basada en rutas. Cada interfaz está asignada exactamente a una zona. Las reglas del cortafuegos se aplicarán posteriormente en gran medida a estas zonas, por lo que la estructura de las zonas no sólo debe planificarse desde el punto de vista técnico, sino también desde el punto de vista de la seguridad.

¿Qué artículo de diseño de red encaja?

Las zonas y las interfaces suelen ser el punto de partida, pero no siempre el objetivo real de la configuración. Dependiendo de la tarea, un artículo más específico encaja mejor:

• Básicamente planificar zonas, interfaces, VLAN, puentes, LAG o RED: Este artículo.
• Configurar la interfaz VLAN con la interfaz principal, DHCP, Device Access y reglas: Sophos Firewall Configurar y probar VLAN.
• Crear y comprender reglas de firewall entre zonas: Comprender y configurar correctamente las reglas Sophos Firewall.
• Compruebe el comportamiento del puente VLAN según SFOS 22: Sophos Firewall Usar puente con etiquetado VLAN.
• Servicios de gestión segura como WebAdmin, SSH, User Portal o DNS: Sophos Firewall Acceso seguro: Configurar Device Access correctamente.
• Clasificar NAT, SNAT, DNAT o MASQ con interfaces y zonas: Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Publicar servidor interno a través de WAN o DMZ: Publicar servidor a través de DNAT en Sophos Firewall.
• Control DNS para dominios internos o zonas AD: Configurar rutas de solicitud de DNS a Sophos Firewall.
• Establecer opciones de DHCP para VoIP, PXE o clientes especiales: Configure las opciones de DHCP en Sophos Firewall.
• Planificar VPN de sitio a sitio con interfaces de túnel: Sophos Firewall Configurar VPN IPsec de sitio a sitio.
• El tráfico no pasa por la zona o regla esperada: Sophos Firewall La regla no aplica: Verifique las causas.Esta separación evita errores típicos de diseño. Una zona no reemplaza una regla de firewall, una VLAN no reemplaza un concepto de seguridad y Device Access no es lo mismo que el tráfico normal entre dos redes. En primer lugar, debería quedar claro qué áreas de seguridad existen. Las interfaces, VLAN, reglas, NAT, DNS y acceso de administración se crean en consecuencia.

Por qué las zonas son importantes

Las zonas en Sophos Firewall son más que una simple agrupación visual. Esto define áreas de seguridad que se utilizan en varios lugares:

• Las reglas de firewall funcionan con Zona de origen y Zona de destino.
• Device Access controla qué servicios de firewall locales son accesibles por zona.
• NAT, SD-WAN, VPN, protección web y registros se hacen más fáciles de entender a través de zonas limpias.
• La solución de problemas se vuelve más clara porque puedes ver inmediatamente de qué área de seguridad proviene un paquete y hacia dónde se supone que debe ir.

Una buena zonificación no previene automáticamente todos los errores, pero sí impone límites claros. Una red de cliente, una red de servidor, una WiFi para invitados y una DMZ no deberían tratarse simplemente como una “LAN” si tienen riesgos y reglas diferentes. De lo contrario, más adelante surgirán reglas de permiso extensas, excepciones poco claras y acceso de administración innecesariamente abierto.

Las buenas zonas siempre responden a esta pregunta: ¿Qué redes tienen el mismo nivel de confianza y pueden tratarse de manera similar? Si dos redes necesitan diferentes derechos de acceso, requisitos de registro o acceso de administración, tiene sentido una zona separada o al menos un concepto de regla muy consciente.

Es importante separar zona y objeto de red. La zona describe por qué área de seguridad entra un paquete en el firewall o hacia dónde debe ir. El objeto de red describe la fuente IP concreta o el destino concreto. Una regla solo queda limpia cuando ambas cosas son correctas: Source zone no debe llamarse simplemente LAN de forma amplia mientras Source networks and devices sigue en Any. A la inversa, un objeto de red correcto ayuda poco si el tráfico entra por otra zona distinta a la esperada.

Comprender las zonas estándar

Sophos Firewall viene con varias zonas estándar:

• LAN: Redes internas, clientes, servidores y redes de gestión.
• WAN: Enlaces ascendentes de Internet, enrutadores de proveedores, PPPoE, DHCP o direcciones WAN estáticas.
• DMZ: Servidores de acceso público, proxies inversos y servicios aislados.
• WiFi: Redes Wi-Fi, Sophos Access Points y segmentos inalámbricos.
• VPN: Remote Access VPN, VPN de sitio a sitio y otros contextos de túnel.

Las zonas estándar se pueden encontrar en Network > Zones. Se pueden crear zonas personalizadas como tipo LAN o DMZ. No se pueden crear libremente zonas WAN o VPN adicionales simplemente porque estos tipos de zonas tienen funciones especiales en el firewall.

Importante: una zona no es un permiso automático. Dependiendo de la dirección y el escenario, también se requieren reglas de firewall adecuadas entre dos interfaces en la misma zona. El tráfico entre dos interfaces de zona LAN no se permite automáticamente, pero requiere una regla de LAN a LAN adecuada.

Sophos Firewall admite zonas propias, pero no como sustituto ilimitado de reglas limpias. El límite oficial es de un máximo de 100 zonas. En la práctica no conviene agotar ese límite. Si casi cada VLAN recibe su propia zona aunque muchas necesiten reglas idénticas y el mismo Device Access, el conjunto de reglas suele volverse más difícil de mantener, no más seguro.

Planificar zonas antes de la creación

Antes de realizar la configuración, debes tener en cuenta qué redes tienen diferentes requisitos de seguridad. Ejemplos típicos:

• LAN del lugar de trabajo
• Red de servidores
• Red de gestión -ZDM
• Wi-Fi para invitados -VoIP
• Cámara o red IoT
• Red de producción
• Clientes VPN
• MPLS o conexiones de ubicación

Una zona separada tiene sentido si una red necesita sus propias reglas, su propio Device Access u otro nivel de confianza. Sin embargo, también pueden estar varias VLAN en la misma zona si se las quiere tratar por igual. Demasiadas zonas no hacen que una configuración sea automáticamente más segura. Las zonas sólo son útiles si detrás de ellas hay reglas claras.

Para muchos entornos pequeños y medianos, esta estructura básica es un buen comienzo:

• LAN o Client: clientes de estación de trabajo normales.
• Server: servidores internos, NAS, servidores de aplicaciones y controladores de dominio.
• Management: Administración de PC, monitoreo, respaldo, administración de conmutadores y firewall.
• Guest o WiFi: Redes WiFi o BYOD para invitados con acceso limitado.
• DMZ: Sistemas que deben ser accesibles desde Internet o desde múltiples redes.
• WAN: Conexiones de Internet y proveedores.
• VPN: Remote Access VPN o contextos VPN de sitio a sitio.

No todas las VLAN necesitan automáticamente su propia zona. Si varias VLAN de clientes obtienen exactamente las mismas reglas de firewall, política web y Device Access, pueden permanecer en una zona de cliente común. Sin embargo, si a una VLAN se le permite llegar a los servidores, a otra solo se le permite acceder a Internet y a una tercera no se le permite tener acceso a los servicios de firewall locales, la separación debe modelarse conscientemente.

Un buen patrón es:

• Otro nivel de confianza: Consulta tu propia zona.
• Acceso de gestión propia al firewall: comprueba tu propia zona o tu propia regla ACL.
• Otras funciones de registro u otras funciones de protección: la propia zona puede resultar útil.
• Solo un rango de IP diferente, pero la misma política de seguridad: el concepto de zona común puede ser suficiente.

Traducir el modelo de zona a una matriz de acceso

Después de la planificación de zonas, debe determinar brevemente qué zona puede comunicarse con qué otra zona. Esta matriz de acceso suele ser más útil que crear reglas inmediatamente en WebAdmin porque hace visibles las contradicciones.

Un ejemplo sencillo:

• Client a WAN: Permitido para Web, DNS, NTP y aplicaciones requeridas.
• Client a Server: Solo puertos de aplicación definidos, no Any.
• Guest a WAN: Permitido, principalmente con política web y registro.
• Guest a Server: Normalmente bloqueado.
• IoT a Server: Sólo para servicios definidos con precisión, por ejemplo MQTT, DNS o NTP.
• Management a LAN, Server, DMZ: Acceso administrativo, estricto y registrado.
• DMZ a LAN: Bloqueado de forma predeterminada, solo permite conexiones de retorno explícitas.
• VPN a Server: Solo se requieren objetivos y servicios internos.

La matriz no tiene por qué ser grande. Lo importante es que cada dirección permitida tenga un propósito. Si una entrada no se puede explicar, no debería surgir como una regla de firewall amplia.

Para cada línea también debes tener en cuenta:

-servicios y puertos requeridos

• si es necesaria la coincidencia de usuarios o grupos
• si NAT está involucrado
• si el registro debe permanecer permanentemente activo
• qué funciones de seguridad son adecuadas, por ejemplo IPS, política web o Application Control
• quién es técnicamente responsable del acceso

A partir de esta matriz se crean las reglas de firewall reales. Las opciones detalladas y los errores típicos para el orden de las reglas, origen, destino, NAT y registro se describen en Comprender y configurar correctamente las reglas Sophos Firewall.

Verificación de planificación antes de cambios.

Antes de crear, mover o eliminar zonas o interfaces, las dependencias deben aclararse por escrito. Muchos errores posteriores no son causados ​​por la dirección IP en sí, sino por reglas de firewall olvidadas, reglas NAT, servidores DHCP, Device Access o decisiones de enrutamiento.

Para cada nueva zona o interfaz, se deben responder al menos estas preguntas:

• Nivel de confianza de la red: De esto dependen la zona, las reglas del firewall y Device Access.
• Usuarios y sistemas en la red: Los clientes, servidores, invitados, IoT, VoIP y administración necesitan reglas diferentes.
• Puerta de enlace predeterminada: El firewall suele ser la puerta de enlace para las VLAN, pero a veces no para las migraciones.
• Fuente DHCP: Sophos Firewall, el servidor DHCP interno o la retransmisión DHCP deben planificarse deliberadamente.
• Servidor DNS: DNS afecta el filtrado web, la resolución de nombres y la resolución de problemas.
• Servicios de firewall local: Device Access para DNS, Ping, HTTPS, SSH o portales deben coincidir.
• Reglas y rutas NAT: Sin el firewall y las reglas NAT adecuados, la interfaz solo está disponible técnicamente.
• Flujo de prueba: Un cliente de prueba, un objetivo de prueba y una entrada de registro esperada ahorran mucho tiempo de búsqueda.

También debería estar disponible una copia de seguridad actual para cambios productivos. Si las interfaces ya están en uso, el uso del objeto es obligatorio antes de cambiar el nombre, el enlace de zona, la dirección IP o el tipo de interfaz.

Crear nueva zona

Abra Network > Zones y haga clic en Agregar.

1. Asigne un nombre corto y único, por ejemplo Server, Guest, Management o MPLS.
2. Seleccione LAN o DMZ como tipo.
3. En Device Access, especifique conscientemente a qué servicios de firewall locales se puede acceder desde esta zona.
4. Guardar.

Después de guardar, conviene comprobar la zona directamente en dos lugares: en Network > Zones para nombre, tipo y Device Access, y más tarde en una regla de firewall de prueba como Source zone o Destination zone seleccionable. Si la zona existe pero no contiene ninguna interfaz, todavía no pasará tráfico productivo por ella.

¿LAN o DMZ como tipo de zona?

Para sus propias zonas normalmente puede elegir entre LAN y DMZ en Sophos Firewall. Ambos tipos agrupan interfaces para que luego puedan usarse limpiamente en reglas, Device Access y políticas. La diferencia radica principalmente en la idea de seguridad detrás de la zona.

LAN se utiliza para redes internas fundamentalmente confiables. Entre ellas se incluyen, por ejemplo, redes de clientes, redes de servidores internas, redes de gestión, VoIP, impresoras o VLAN internas. Lo mismo se aplica a una zona LAN: el tráfico entre interfaces no se permite automáticamente. Si dos zonas LAN o dos interfaces dentro de una zona LAN deben comunicarse entre sí, se requieren reglas de firewall adecuadas.DMZ se utiliza para redes con mayor riesgo o aislamiento claro. Ejemplos típicos son servidores web de acceso público, servidores proxy inversos, puertas de enlace de correo, hosts de salto o sistemas a los que se debe poder acceder desde múltiples áreas de seguridad. Se debe planificar una DMZ de modo que solo reciba las conexiones internas necesarias. Si un servidor comprometido está en la DMZ, esto no debería resultar automáticamente en un acceso generalizado a la LAN interna.

Como regla general simple:

• LAN: redes internas que generalmente son confiables y que se comunican principalmente de forma saliente o interna.
• DMZ: redes expuestas o particularmente aisladas donde el acceso interno debe estar estrictamente limitado.

Las interfaces HA también pertenecen a una zona DMZ. Para redes normales de administrador o cliente, LAN suele ser el tipo más adecuado.HTTPS puede resultar útil para una red de administración interna. Para redes normales de clientes o invitados, se debe evitar el acceso de administración. Ping/ping6 suele ser útil para solucionar problemas, pero debe activarse conscientemente. DNS solo es necesario si los clientes de esta zona utilizan el firewall como servidor DNS.

⚠️ Device Access no es lo mismo que una regla de firewall. El acceso a los servicios de firewall locales, por ejemplo WebAdmin, SSH, User Portal, DNS o Ping, se controla mediante Administration > Device access y excepciones de ACL locales.

Configurar interfaz

Las interfaces se pueden encontrar en Network > Interfaces. Por ejemplo, un puerto físico puede funcionar como LAN, WAN o DMZ. También se crean interfaces virtuales como VLAN, Bridge, LAG, RED o XFRM.

Estos puntos son particularmente importantes para una interfaz física:

• Name: nombre descriptivo para reglas y registros posteriores.
• Hardware: puerto físico, por ejemplo Port1, Port2 o PortA.
• Network zone: Zona de seguridad en la que se encuentra la interfaz.
• IPv4 configuration: Estático, DHCP o PPPoE.
• IPv6 configuration: Estático, DHCP o Delegado, según el entorno.
• Gateway: solo relevante para interfaces WAN.
• MTU / MSS: importante para PPPoE, VPN, SD-WAN y problemas de fragmentación.

Solo las interfaces en la zona WAN reciben una configuración de puerta de enlace. Las interfaces internas normalmente se abordan de forma estática. DHCP o PPPoE pueden resultar útiles para las conexiones de proveedores.

Si el proveedor proporciona IPv6 mediante delegación de prefijo, debe planificar las restricciones y el proceso por separado. El artículo práctico para esto es Configurar la delegación de prefijo IPv6 en Sophos Firewall.

Los nombres significativos son importantes. PortD significa poco en seis meses. Server VLAN, MPLS Provider, Guest WiFi o Core Switch Trunk ayudan mucho más durante la operación.

Una interfaz física existente se edita así:

1. Abrir Network > Interfaces.
2. Abrir el menú del puerto deseado y elegir Edit interface.
3. Comprobar Name, Network zone, configuración IP, gateway y MTU/MSS.
4. En interfaces WAN, comprobar también el nombre del gateway y la IP del gateway.
5. Guardar y después revisar link status, gateway status y Log Viewer.

Antes de cambiar una interfaz productiva debe abrirse Object usage. Los cambios de interfaz pueden afectar zone binding, DNS, gateways, SD-WAN routes, hosts basados en interfaz, interfaces VLAN, Dynamic DNS, reglas de firewall y NAT. Al eliminar una interfaz virtual, Sophos también elimina configuraciones dependientes como reglas de firewall, referencias DHCP o routing. Precisamente ahí aparecen las interrupciones incómodas cuando solo se tenía en mente el nombre del puerto.

Antes de actualizar firmware, también conviene asegurarse de que los nombres de interfaces, hardware y branches no terminen con un bloque largo de números. En las release notes de SFOS está documentado un error de visualización de WebAdmin cuando esos nombres terminan con diez o más dígitos, por ejemplo VLAN_1234567890. Verifique Sophos Firewall antes de la actualización a SFOS 22 es adecuado para la planificación de actualizaciones y pruebas concretas.

Crear interfaz VLAN

Para un proceso enfocado con interfaz principal, etiquetado de conmutadores, DHCP, Device Access, reglas y pruebas de firewall, Sophos Firewall Configurar y probar VLAN es adecuado. La siguiente sección clasifica las VLAN dentro del modelo de zona e interfaz más grande.

Se crea una interfaz VLAN en Network > Interfaces > Add interface > Add VLAN. La interfaz principal, la zona, el ID de VLAN y la configuración de IP son particularmente importantes.

La interfaz principal es el puerto físico o un LAG en el que llega etiquetada la VLAN. Si el conmutador envía la VLAN a un puerto diferente, sin etiquetar o con una ID de VLAN incorrecta, el firewall ve una interfaz VLAN, pero los clientes no pueden alcanzarla de manera confiable.

Para las VLAN internas, normalmente se utiliza una dirección IP estática en el firewall, por ejemplo como puerta de enlace predeterminada para esta VLAN. Posteriormente, la zona decide qué reglas de firewall, políticas web y configuraciones Device Access se aplican. Esta es exactamente la razón por la que no solo debe ingresar la dirección IP al crear una VLAN, sino también considerar directamente si la VLAN requiere Client, Server, Management, Guest, DMZ u otra zona.

En Configure VLAN en Sophos Firewall y UniFi Switch se puede encontrar un ejemplo práctico concreto con perfiles de puerto de switch, comportamiento etiquetado/sin etiquetar, DHCP y secuencia de prueba.

En hardware XGS, Sophos no indica un número fijo y duro de interfaces VLAN por interfaz física. Eso no significa que un único parent port sea siempre la mejor decisión operativa. Para rendimiento, troubleshooting y mantenibilidad, las VLAN deben distribuirse de forma sensata entre puertos físicos o LAGs, especialmente cuando hay muchas VLAN, mucha carga este-oeste o diseños HA.

Implementación limpia de VLAN

Una VLAN solo se considera completa cuando no solo se ha creado la interfaz, sino que también encajan el conmutador, DHCP, DNS, las reglas de firewall y el registro. Especialmente con redes nuevas, es fácil buscar en el lugar equivocado: la regla del firewall parece correcta, pero el conmutador envía sin etiquetar. O el cliente obtiene una dirección IP, pero Device Access no permite el acceso DNS al firewall.

Para cada nueva VLAN, se deben verificar estos puntos:

• Interfaz de firewall: ID de VLAN, interfaz principal, zona, dirección IP y máscara de subred coinciden con el diseño.
• Puerto del conmutador: El enlace ascendente al firewall está configurado como troncal y tiene la VLAN etiquetada.
• Puerto de acceso o SSID: El puerto del cliente o el SSID de WLAN asigna a los clientes a la VLAN correcta.
• Puerta de enlace: La IP del firewall en la VLAN es la puerta de enlace predeterminada esperada o el enrutamiento está documentado de manera diferente.
• DHCP: El servidor DHCP, la retransmisión DHCP o el servidor DHCP externo distribuyen la IP, la puerta de enlace, el DNS y el arrendamiento correctos.
• DNS: Los clientes pueden resolver nombres internos y externos según lo planeado.
• Device Access: Solo se permiten servicios de firewall locales requeridos desde la zona, por ejemplo DNS o Ping.
• Regla de firewall: La zona de origen, la red de origen, la zona de destino, los servicios y el registro coinciden con el flujo de prueba.
• NAT: Sólo activo si el tráfico realmente necesita ser traducido. Para el tráfico interno normal, la NAT suele ser incorrecta.
• Prueba: Log Viewer muestra el firewall esperado Rule ID; si es necesario, Packet Capture confirma el flujo de paquetes.

Como prueba de aceptación, no basta con que un cliente reciba una dirección IP. Una prueba útil consta de varios pasos: conectar el cliente a través de DHCP, hacer ping a la puerta de enlace, verificar el DNS, probar una conexión interna permitida, verificar que el acceso prohibido esté bloqueado deliberadamente y luego verificar el acceso a Internet. De esta manera podrá ver si la VLAN, la zona, Device Access, la regla de firewall y NAT realmente coinciden.

Si se crean varias VLAN al mismo tiempo, debe utilizar un cliente de prueba independiente o al menos una IP de prueba única para cada VLAN. De lo contrario, Log Viewer y Packet Capture resultarán innecesariamente confusos. Pruebe la regla de firewall con Log Viewer, Policy Test y Packet Capture es adecuado para la verificación del flujo de paquetes real.

Leer el estado de la interfaz correctamente

En Network > Interfaces, Sophos Firewall muestra mensajes de estado. Estos mensajes de estado son muy útiles a la hora de solucionar problemas porque puede ver rápidamente si una interfaz está configurada incorrectamente o si realmente no hay ningún enlace.

• Not configured: La interfaz no está asignada a una zona. Por lo tanto, no se puede utilizar de manera significativa hasta que se haya vinculado una zona.
• Connected: La interfaz está configurada y conectada.
• Connecting: Actualmente se está obteniendo una nueva dirección IP, por ejemplo a través de DHCP.
• Disconnected: La dirección IP ha sido publicada.
• Disconnecting: La dirección IP se está publicando actualmente.
• Unplugged: No hay conexión física. Para WiFi también puede significar que no hay ningún Access Point conectado o que no hay ninguna red inalámbrica asignada.
• Not available: Los puertos FleXi se han configurado, pero el módulo de puerto FleXi correspondiente ya no está presente.

Si una interfaz muestra inesperadamente Not configured o Unplugged, no debe buscar reglas de firewall primero. Primero verifica la vinculación de zona, el enlace, el SFP/transceptor, el cable, el puerto del switch y, para DHCP/PPPoE, la asignación de dirección.

Clasificar VLAN, Bridge, LAG, Alias y RED

Sophos Firewall admite diferentes tipos de interfaz. Para los principiantes, lo más importante es saber qué tipo tiene sentido.

• VLAN: ​​​​Estándar para redes segmentadas en un puerto troncal.
• Puente: Conexión transparente de múltiples puertos, a menudo para configuraciones o migraciones simples.
• LAG: Agrupación de múltiples enlaces físicos para redundancia o ancho de banda.
• Alias: dirección IP adicional en una interfaz existente.
• RED: Dispositivo Ethernet remoto para ubicaciones externas.
• XFRM: Interfaz VPN IPsec basada en rutas.

Las interfaces Alias suelen infravalorarse. Son especialmente útiles cuando un proveedor entrega varias direcciones IP públicas en la misma subred. Varias interfaces WAN separadas en la misma subred provocan problemas ARP en Sophos Firewall y pueden hacer que los gateways no sean alcanzables. En esos diseños, un Alias en la interfaz WAN existente o un LAG bien planificado suele ser la mejor opción.

Para instalaciones nuevas, la VLAN en un enlace ascendente claramente definido hacia el conmutador suele ser más limpia que un puente grande sobre muchos puertos. Un puente puede resultar útil para migraciones o configuraciones muy simples porque varios puertos se tratan como un segmento común de Capa 2. Pero esa es exactamente la desventaja: los límites de seguridad, los dominios de transmisión y las fuentes de error se vuelven menos visibles.

Por eso recomendamos puentes únicamente de forma específica y no como diseño estándar. En la práctica, los puentes tienen varias desventajas:

• Múltiples puertos comparten el mismo segmento de Capa 2, lo que hace que las transmisiones y las interferencias afecten más fácilmente a múltiples dispositivos.
• Las reglas del firewall son cada vez menos claras porque la separación ya no es claramente visible entre sus propias interfaces, VLAN y zonas.
• La resolución de problemas se vuelve más difícil ya que se deben considerar en conjunto el flujo de paquetes, el aprendizaje de MAC, los problemas de STP y la configuración del conmutador.
• La segmentación posterior se vuelve más compleja si se van a crear redes separadas de clientes, servidores, invitados o de administración a partir de un simple puente.
• Los diseños de acceso a dispositivos, HA, VLAN, DHCP o se vuelven confusos rápidamente si se ejecutan demasiadas funciones a través de un puente.

Los puentes se pueden crear en Sophos Firewall a través de interfaces físicas, interfaces RED, VLAN o LAG y operar con o sin su propia dirección IP. Precisamente aquí es donde suelen surgir malentendidos:

• Sin una dirección IP, el puente funciona de forma transparente, pero no se puede utilizar como una interfaz enrutada normal.
• Si se requiere enrutamiento en un puente, se debe asignar al puente una dirección IP.
• Para el tráfico entre miembros del puente, aún se requieren reglas de firewall apropiadas entre las zonas involucradas, por ejemplo de LAN a LAN.
• STP puede resultar útil si hay rutas redundantes y se deben evitar bucles de puente. Sin embargo, con HA activo no se puede activar STP en interfaces Bridge.
• Los filtros VLAN y los filtros EtherType pueden ayudar a limitar el tráfico de Capa 2 que pasa a través de un puente. Si un filtro VLAN está activado pero no se han introducido VLAN permitidas, el firewall descarta el tráfico etiquetado de todas las VLAN. El tráfico sin etiqueta no se ve afectado.
• El tráfico a través de interfaces de puente sin una dirección IP se puede eliminar si alcanza una regla de firewall con filtrado de proxy web o una regla NAT. Estas caídas no se registran. Con NAT debe prestar especial atención a la traducción de origen o anular la traducción de origen.

Este último punto es importante: si de repente no ve ningún registro sobre un puente, aunque el tráfico no parezca funcionar, el problema no siempre está en Log Viewer. Podría deberse al modo puente, NAT o filtrado de proxy web.

Si ya existen VLAN en el conmutador, el firewall debe adoptar conscientemente estas VLAN como sus propias interfaces VLAN. Esto da como resultado zonas más claras, reglas de firewall más limpias y, por lo general, es más fácil de mantener a largo plazo.

SFOS 22: Verifique el tráfico de puentes, SNAT y horquillas

Con SFOS 22 existe un caso especial de puente adicional que rápidamente se pasa por alto en las migraciones. El enrutamiento a través de una interfaz de puente puede fallar si se aplica SNAT o MASQUERADE al tráfico a través del puente y se puede acceder al origen y al destino a través del mismo miembro físico del puente. En este escenario de horquilla, los paquetes de respuesta se pueden descartar en el puente sin que la caída sea claramente visible en drppkt.

Este no es un problema normal de coincidencia de reglas. Si Log Viewer muestra poco, la regla parece correcta y aún así solo fallan ciertas conexiones a través de un puente, debe verificar NAT y la topología del puente juntos:

• ¿Es realmente necesario SNAT o MASQUERADE en el tráfico de puentes?
• ¿El origen y el destino llegan a través del mismo puente físico?
• ¿Solo hay un miembro del puente que se utiliza activamente?
• ¿Sería más limpio un diseño enrutado o una interfaz física dedicada?
• ¿Se puede probar el tráfico sin la traducción del origen?

También hay un caso SFOS 22 separado para el tráfico etiquetado con VLAN al propio firewall. El procedimiento práctico está en Sophos Firewall Verifique las VLAN del puente según SFOS 22.

RED Bridge: extender la red a través de ubicaciones

Es técnicamente posible incluir interfaces RED en un puente y así extender una red de Capa 2 a través de múltiples ubicaciones. Esto puede ayudar en casos especiales, por ejemplo, cuando una aplicación debe permanecer en la misma subred o debe realizarse una migración sin cambios inmediatos de IP.

Sólo recomendamos este diseño con mucha cautela. Un puente sobre RED extiende el dominio de Capa 2 sobre el túnel. Esto hace que las transmisiones, ARP, paquetes de unidifusión desconocidos y otros efectos de Capa 2 se ejecuten a través de una conexión WAN o de Internet. Esto puede empeorar el rendimiento y hacer que los errores sean más difíciles de entender. Si el túnel RED es inestable, esto también afectará directamente a la red extendida.

En la mayoría de los casos, un diseño enrutado es mejor: cada ubicación tiene sus propias subredes, las rutas del firewall entre las redes y las reglas del firewall definen específicamente lo que está permitido. Esto es más limpio, más escalable y mucho más conveniente a la hora de solucionar problemas.

LAG: Planificar correctamente la redundancia y el ancho de banda

Un Grupo de agregación de enlaces (LAG) combina varios puertos físicos en una interfaz lógica. Esto tiene sentido si necesita redundancia para el conmutador central o desea proporcionar más ancho de banda entre el firewall y el conmutador. Pero el GAL no reemplaza la zonificación limpia. Al final, la interfaz LAG sigue siendo sólo una interfaz en la que se pueden, por ejemplo, operar VLAN o asignar una zona.

Sophos Firewall admite principalmente dos modos de funcionamiento típicos:

• Active-Backup: Un enlace está activo, otro asume el control si falla. Esto es simple y bueno para la redundancia.
• LACP (802.3ad): Se pueden utilizar varios enlaces en paralelo. Esto requiere LACP en ambos lados, es decir, en el firewall y en el switch.

Es importante: LACP sólo funciona correctamente si el otro lado está configurado correctamente. En el conmutador, los puertos deben estar en el mismo grupo LAG, usar la misma velocidad y modo dúplex y coincidir con la configuración del firewall. Si solo crea un LAG en el firewall pero no configura el conmutador adecuadamente, a menudo surgen pérdidas de paquetes difíciles de entender o problemas de conexión asimétrica.

Se aplican algunas limitaciones prácticas a los GAL:

• Un LAG en Sophos Firewall consta de dos a cuatro interfaces físicas.
• Sólo las interfaces físicas independientes con configuración estática son adecuadas como miembros.
• Las interfaces PPPoE, Cellular WAN y WLAN no se pueden utilizar como miembros de LAG.
• Para LACP (802.3ad), los puertos miembros deben tener el mismo tipo y velocidad.
• xmit-hash-policy determina cómo se distribuyen las sesiones entre los enlaces. Normalmente, una única sesión TCP no se vuelve más rápida de repente porque normalmente permanece en un enlace.

Para entornos pequeños, un único puerto troncal limpio suele ser suficiente. LAG es especialmente útil si el conmutador central se va a conectar de forma redundante, si muchas VLAN se ejecutan en el mismo enlace ascendente o si el firewall realmente necesita más rendimiento para el conmutador.

XFRM: Comprender IPsec basado en rutas como una interfazUna interfaz XFRM pertenece al tema VPN IPsec basada en rutas. No está planificado como una VLAN normal o un puerto físico, sino que se crea en el contexto de una conexión IPsec. Sophos Firewall crea una interfaz XFRM automáticamente cuando las subredes local y remota están configuradas en Any en una conexión IPsec.

Ésta es una diferencia importante con respecto a los túneles IPsec clásicos basados ​​en políticas. Con una VPN basada en rutas, no sólo la política IPsec, sino también el enrutamiento, las reglas de firewall y la interfaz XFRM deciden hacia dónde va el tráfico. Esto hace que las conexiones de sitios más complejas sean más flexibles, pero requiere una planificación cuidadosa:

• La interfaz XFRM está en la zona VPN.
• Bajo Administration > Device access, se debe permitir IPsec para la zona WAN para que se pueda establecer la conexión.
• Si las subredes locales o remotas no son Any, no se crea ninguna interfaz XFRM.
• MTU y MSS son particularmente importantes para VPN basada en rutas porque IPsec genera una sobrecarga adicional. El procedimiento de prueba práctica se encuentra en Sophos Firewall Verifique MTU y MSS para detectar problemas de VPN.
• Una interfaz XFRM no se desactiva directamente en Network > Interfaces, sino a través de la conexión IPsec asociada en Site-to-site VPN > IPsec.

XFRM es particularmente relevante para los administradores cuando el enrutamiento SD-WAN, el enrutamiento dinámico o múltiples redes deben controlarse adecuadamente a través de un túnel de ubicación. Si todo lo que necesita es una conexión muy simple de sitio a sitio con dos redes fijas, un túnel clásico basado en políticas suele ser más fácil de entender.

ROJO: ubicaciones externas como concepto de interfaz independiente

Las interfaces RED no son un puerto de conmutador normal. ROJO significa Dispositivo Ethernet remoto y se utiliza para conectar una ubicación externa al Sophos Firewall a través de un túnel cifrado. Esto se puede implementar con hardware SD-RED dedicado o con conexiones RED de firewall a firewall.

Antes de planificar, debe quedar claro qué modo de funcionamiento se requiere:

• Standard/Unified: El firewall administra la red remota. El tráfico pasa a través del firewall central. Muy fácil de controlar, pero dependiente del túnel.
• Standard/Split: Solo las redes de destino definidas pasan por el túnel, el tráfico de Internet sale localmente en la ubicación. Menos ancho de banda en la sede, pero menos control central.
• Transparent/Split: RED se cuelga de forma transparente en una red existente. Bueno para casos especiales, pero más difícil de entender y no adecuado para todos los diseños.
• Manual/Split: Más configuración de red manual. El sitio puede continuar operando localmente si el túnel falla.

Para muchas empresas, Standard/Unified es la opción más limpia si la ubicación necesita estar completamente protegida a través del firewall central. La desventaja es clara: si el túnel RED falla, el lugar también pierde el acceso a Internet controlado centralmente, dependiendo del diseño. Standard/Split reduce esta dependencia, pero también significa que el tráfico local de Internet ya no se filtra ni se registra por completo a través del Sophos Firewall central.

Con RED debes comprobar estos puntos con antelación:

-El servicio RED debe estar activado en System services > RED.

• Para la conexión normalmente se requieren TCP 3400, UDP 3410 y NTP 123.
• Los dispositivos SD-RED necesitan la hora correcta; de lo contrario, el protocolo de enlace TLS y el establecimiento del túnel pueden fallar.
• Cuando se pone en marcha por primera vez, DHCP en el enlace ascendente suele ser más fácil porque el dispositivo tiene que lograr el aprovisionamiento.
• Las VLAN no son igualmente útiles en todos los modos RED. Standard/Split y Transparent/Split no están destinados a tramas etiquetadas con VLAN. Si detrás de una SD-RED se necesitan VLAN, se debe elegir el modo de funcionamiento con especial atención.
• Si un dispositivo RED está detrás de un enrutador de proveedor, las conexiones salientes y DNS/NTP deben funcionar.

RED es muy conveniente para sitios pequeños, pero no debes tratarlo como un cable LAN normal. Lo decisivo es si el lugar debe estar protegido centralmente, ser autónomo localmente o estar conectado sólo parcialmente a través del túnel. Esta decisión afecta a DHCP, DNS, VLAN, enrutamiento, reglas de firewall, registro y solución de problemas.

Restringir Device Access limpiamente

En Administration > Device access puede ver a qué servicios de firewall locales se puede acceder desde qué zonas. Estos incluyen, entre otros:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Para entornos productivos, cuantos menos servicios locales se puedan alcanzar desde una zona, mejor. En particular, HTTPS y SSH solo deben permitirse desde redes de administración confiables o mediante una regla de excepción de ACL de servicio local.

Si se necesita SSH, esta guía le ayudará: Establezca una conexión SSH con Sophos Firewall.

En zonas propias, Device Access también puede estar visible directamente al crear o editar la zona. Técnicamente sigue tratándose de servicios locales del firewall, no de tráfico de paso normal. Si los clientes usan el firewall como servidor DNS, DNS debe estar permitido para esta zona. Si los administradores deben acceder a WebAdmin, no debería habilitarse de forma amplia para toda la zona de clientes, sino mediante una red de management o una excepción Local Service ACL.

Tenga en cuenta las dependencias

Los cambios en interfaces rara vez son aislados. Zone binding, DNS, gateways, SD-WAN routes, hosts basados en interfaz, interfaces VLAN, Dynamic DNS, reglas de firewall y reglas NAT pueden depender de la misma interfaz. Antes de cambios importantes conviene comprobar en Object usage dónde se usa ya una interfaz, una zona o un objeto host. Sophos Firewall muestra el uso de objetos y enlaza directamente muchas configuraciones dependientes.

Debe tener especial cuidado al desactivar o eliminar:

• Si se desactiva una interfaz, la configuración se conserva y el estado sigue siendo visible.
• Los túneles IPsec de sitio a sitio donde el firewall es el iniciador se desconectan inmediatamente.
• Los túneles IPsec de sitio a sitio como respondedores y conexiones de acceso remoto se desconectan a más tardar debido a inactividad o detección de pares inactivos.
• Las interfaces Alias ​​y XFRM no se pueden desactivar directamente como las interfaces normales. Las interfaces alias siguen la interfaz física, las interfaces XFRM se desactivan mediante Site-to-site VPN > IPsec.
• Cuando se elimina una interfaz virtual, se pueden eliminar con ella las reglas de firewall dependientes, las configuraciones de DHCP, las entradas ARP, las rutas, los hosts de la interfaz y otras referencias.

Por lo tanto, antes de eliminar, siempre debe verificar si la interfaz se utiliza en reglas de firewall, reglas NAT, DHCP, enrutamiento, SD-WAN, DNS dinámico u objetos de host. Una eliminación descuidada puede eliminar algo más que la propia interfaz.

Implementar cambios de forma segura

Los cambios de interfaz deben ser graduales. Las ubicaciones remotas, los clústeres HA, las interfaces WAN, las troncales VLAN, las interfaces XFRM y las redes de administración son particularmente críticas. Un pequeño cambio en el enlace de zona puede ser suficiente para que las reglas de firewall, Device Access o las rutas SD-WAN ya no funcionen como se esperaba.

Proceso probado:

1. Documentar la interfaz actual y la configuración de zona.
2. Verificar las dependencias mediante Object usage y anotar directamente los resultados más importantes.
3. Cree una copia de seguridad.
4. Defina la ventana de mantenimiento o el tiempo de recuperación.
5. Primero agregue una nueva zona o una nueva interfaz, no elimine inmediatamente la configuración anterior.
6. Prepare el cliente de prueba o el tráfico de prueba.
7. Después de realizar el cambio, verifique el estado del enlace, la dirección IP, la puerta de enlace, DHCP y DNS.
8. Valide la regla de firewall, la regla NAT y Device Access con Log Viewer o Packet Capture.
9. Elimine las reglas, interfaces u objetos antiguos únicamente una vez que la nueva ruta sea estable.

Una copia de seguridad es sólo una parte del camino de regreso. Antes de cambios críticos de interfaz o zona, también se debe documentar qué dirección IP anterior, zona, ID de VLAN, puerta de enlace, ruta, ruta SD-WAN, regla de firewall y regla NAT deben restaurarse en caso de una interrupción. Sophos Firewall Crear o restaurar copia de seguridad es adecuado para el proceso de copia de seguridad y restauración real.

• Se ajusta la zona de administración o Device Access: Se prueba el acceso de administrador alternativo antes de eliminar la accesibilidad anterior.
• Se cambia la interfaz WAN o la puerta de enlace: La ruta del proveedor anterior, los valores PPPoE/DHCP/estáticos y la ruta SD-WAN están documentados.
• Se está convirtiendo la troncal de VLAN: ​​La ID de VLAN anterior, la VLAN nativa, el perfil del puerto del switch y la interfaz del firewall son rastreables.
• Se cambia el puente, LAG o RED: El estado del enlace, los puertos involucrados y el acceso a la ubicación se pueden verificar de forma independiente.
• Se cambia la interfaz XFRM o VPN: Las reglas de túnel, enrutamiento y firewall se validan antes de eliminar la ruta anterior.

Se debe prestar especial atención al comportamiento etiquetado/sin etiquetar durante las migraciones de VLAN. Si el conmutador y el firewall utilizan diferentes ID de VLAN, VLAN nativas o perfiles troncales, el firewall no ve ningún tráfico o el tráfico termina en la zona incorrecta.

Para ubicaciones remotas, siempre debe haber una ruta de acceso fuera de la interfaz que acaba de cambiar. Puede ser Sophos Central, un segundo acceso WAN, un administrador local en el sitio o una red de administración separada.

Obstáculos típicos

La interfaz está libre o deshabilitada: Primero verifique si hay una zona asignada. No se puede eliminar una interfaz física, pero se puede eliminar su configuración estableciendo la zona en None.

La VLAN no funciona: Verifique la ID de VLAN, el puerto del conmutador, la configuración etiquetada/sin etiquetar, la VLAN nativa y la interfaz principal.

Los clientes no pueden acceder al firewall mediante ping o HTTPS: No verifique primero las reglas normales del firewall. Administration > Device access y las excepciones de ACL locales son cruciales.

El tráfico entre dos redes internas no funciona: Verifique la zona de origen, la zona de destino, los objetos de la red, el enrutamiento y la posición de la regla del firewall.

La puerta de enlace WAN no se activa: Verifique la configuración IP, la IP de la puerta de enlace, el estado del enlace, las credenciales PPPoE, el DNS y, si es necesario, el administrador de enlaces WAN.

Múltiples interfaces WAN en la misma subred: Si varias interfaces WAN usan direcciones IP de la misma subred, pueden ocurrir problemas de ARP y las puertas de enlace pueden volverse inalcanzables. Si un proveedor proporciona varias IP públicas en la misma subred, las interfaces alias o LAG suelen ser más limpias que varias interfaces WAN independientes en la misma red.

SFP, la velocidad del puerto o la conexión no coinciden: La velocidad del puerto en el conmutador, enrutador, transceptor y firewall debe coincidir. Un puerto de 25 Gbit/s no se puede conectar directamente a un puerto de 40 Gbit/s sin la tecnología adecuada. Para los modelos con puertos 40G o 100G, los cables multiconector pueden ser relevantes si un puerto se va a dividir en varios puertos más pequeños.

Problemas de MTU con VPN o PPPoE: Verifique MTU y MSS. Para el tráfico VPN, un valor de MTU demasiado alto puede provocar la pérdida de paquetes, lo que en la vida cotidiana parece problemas de conexión aleatorios. Sophos Firewall Verifique MTU y MSS para detectar problemas de VPN es adecuado para la limitación sistemática.

Solución de problemas

Este orden es práctico para solucionar problemas:

1. Network > Interfaces: Verifique el estado del enlace, la dirección IP, la zona y la puerta de enlace.
2. Network > Zones: Verifique Device Access y el tipo de zona.
3. Hosts y servicios: compruebe si los objetos de host y servicio son correctos.
4. Rules and policies > Firewall rules: Consulta zona origen, zona destino, servicios y pedido.
5. Rules and policies > NAT rules: Si hay NAT involucrado, compare cuidadosamente el original y la traducción.
6. Visor de registros: compruebe qué regla o eliminación se aplica.
7. Diagnostics > Tools > Packet capture: Verifique si los paquetes llegan y dónde se reenvían.

Si las zonas e interfaces están distribuidas correctamente, el siguiente paso resulta mucho más sencillo: Comprender y configurar correctamente las reglas Sophos Firewall. Si el tráfico no funciona a pesar de la zona aparentemente correcta, la lista de verificación La regla del firewall no funciona: verifique el orden, las coincidencias y los registros le ayudará. Para un análisis más profundo también puedes usar Utilice Packet Capture en WebAdmin y para traducciones o reenvío de puertos el artículo Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Lista de verificación operativa

• Modelo de zona documentado: cliente, servidor, administración, invitado, DMZ, WAN y VPN deliberadamente separados o combinados deliberadamente.
• Nuevas VLAN documentadas con ID de VLAN, interfaz principal, perfil de puerto de switch e IP de puerta de enlace.
• Zona y objeto host IP concreto documentados para cada red importante.
• Device Access verificado por zona, especialmente para HTTPS, SSH, DNS, Ping, User Portal y VPN Portal.
• Reglas de firewall creadas con zona de origen, zona de destino, servicios y registro.
• Alias comprobado en lugar de una interfaz WAN adicional cuando se usan varias IP públicas en la misma subred del proveedor.
• Se verifican las reglas NAT si se trata de acceso a Internet, DNAT, SNAT o VPN.
• DHCP, DNS y NTP probados para redes nuevas.
• Se verifica el uso de objetos antes de realizar cambios en las interfaces existentes.
• Estado del enlace, Log Viewer y Packet Capture comprobados en busca de cambios.
• Acceso de gestión asegurado a través de un camino independiente.
• Copia de seguridad disponible antes de cambios importantes.

Preguntas frecuentes