Configurar y probar una ruta estática en Sophos Firewall

Una ruta estática indica a Sophos Firewall mediante qué next hop fijo o interfaz de túnel debe alcanzar un destino determinado. Es adecuada cuando la ruta está definida y no se necesita seleccionar por origen, servicio, aplicación o calidad del enlace.

Respuesta breve

Una ruta IPv4 se crea aquí:

Routing > Static routes > IPv4 unicast route > Add

Para una red de destino 10.20.0.0/24, accesible mediante el router 192.0.2.2 en Port4, se introducen estos valores:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

La red de destino, el gateway y la interfaz deben corresponder al entorno real. No se deben reutilizar Administrative Distance y Metric sin comprobar antes las rutas existentes hacia el mismo destino; 1 y 10 son solo valores de ejemplo.

A continuación, se comprueba el destino 10.20.0.10 en Diagnostics > Tools > Route lookup. Si el resultado muestra Port4, la decisión de routing es correcta. El cambio solo queda completamente validado cuando funciona una conexión real desde el cliente y regresa la respuesta.

Para que el tráfico funcione, también se necesita una regla de firewall adecuada y una ruta de retorno en el equipo remoto. Una ruta estática no permite tráfico ni aplica NAT automáticamente.

Entender el ejemplo

El ejemplo utiliza la siguiente topología:

La red de clientes detrás de Sophos Firewall es 10.10.0.0/24.
El cliente de prueba en esta red es 10.10.0.10.
Port4 del firewall tiene la IP de tránsito 192.0.2.1/30.
El siguiente router tiene la IP 192.0.2.2 en esta red.
La red de destino 10.20.0.0/24 está detrás de este router.
El sistema de prueba es 10.20.0.10.

Destination siempre es el destino remoto, no el siguiente router. Gateway IP es el next hop directamente accesible que reenvía el paquete. Interface es el puerto o la interfaz de túnel por los que se alcanza ese next hop.

El destino puede ser una red o un único host. Si solo el sistema de prueba debe utilizar esta ruta, se puede introducir 10.20.0.10/32 para IPv4 o 2001:db8:20::10/128 para IPv6 en lugar de una red completa. Un prefijo más amplio incluye otras direcciones de destino y solo debe elegirse si también son accesibles mediante este next hop. La autorización del firewall sigue siendo independiente.

En Gateway IP se introduce directamente la dirección; no hace falta un objeto de gateway en Routing > Gateways. Para adaptar el ejemplo al entorno propio, se deben sustituir conjuntamente la red de destino, el gateway y la interfaz. Si solo se cambia una dirección del ejemplo, la ruta puede guardarse, pero apuntar a la red equivocada o a un router inaccesible. La IP del gateway debe pertenecer a la red de la interfaz seleccionada.

Si, en cambio, la ruta debe tener su propio Health Check o poder seleccionarse en una SD-WAN Route, resulta útil el procedimiento específico para Custom Gateways en Sophos Firewall.

Los fundamentos sobre puertos, zonas e IP de interfaz se explican en Configurar zonas e interfaces en Sophos Firewall.

Cuándo conviene usar una ruta estática

Este artículo trata redes de destino unicast. Si un emisor debe alcanzar un grupo multicast a través de varias interfaces, se utiliza el procedimiento específico para configurar multicast con una ruta multicast estática.

Multicast envía un único flujo a un grupo en lugar de copias independientes a cada destinatario, por ejemplo para videoconferencias, formación o distribución de software. Los destinatarios deben unirse al grupo; emisores, destinatarios y routers implicados deben admitir multicast. Las direcciones de grupo IPv4 van de 224.0.0.0 a 239.255.255.255, mientras que el origen sigue siendo una dirección unicast. Este es el rango general, no una autorización para utilizar todos sus destinos en una ruta multicast estática. En Routing > Static routes, Enable multicast forwarding activa el reenvío. Manage multicast route permite añadir, editar, eliminar y filtrar por IP de origen, IP multicast, Source Interface o Destination Interface. El procedimiento multicast enlazado explica los requisitos, el rango permitido, la prueba segura y el rollback.

Una ruta estática resulta útil cuando una red siempre es accesible mediante el mismo next hop, por ejemplo:

una red de sucursal detrás de un Core Router interno
una red de servidores detrás de un switch de Layer 3
una red detrás de un túnel RED
una red remota mediante una interfaz XFRM de un túnel IPsec basado en rutas

Si el firewall también debe decidir según el origen, el servicio o la aplicación, o cambiar de ruta en función de la latencia, el jitter y la pérdida de paquetes, una ruta SD-WAN suele ser la opción más adecuada. En dominios de routing pequeños o existentes, RIPv2 puede intercambiar automáticamente redes sencillas. En redes grandes que cambian con frecuencia, OSPF o BGP reducen el mantenimiento manual.

Configurar una ruta IPv4

Antes del cambio, se documentan la red de destino, el next hop, la interfaz de salida, la zona esperada, la ruta de retorno y un host de prueba accesible. A continuación:

Abrir Routing > Static routes.
En IPv4 unicast route, hacer clic en Add.
Introducir 10.20.0.0/24 en Destination IP / Netmask.
Introducir el siguiente router 192.0.2.2 en Gateway IP.
Seleccionar Port4 como Interface.
Establecer Administrative distance en 1.
Introducir 10 en Metric.
Añadir una Description inequívoca, como Branch_10.20_via_Core.
Guardar con Save.

Para esta ruta, Sophos Firewall tiene en cuenta primero la interfaz seleccionada y después el gateway. Si uno de los dos campos es incorrecto, no se alcanza el next hop previsto. En la lista IPv4 se puede filtrar por dirección IP, Gateway IP, Interface o Description, además de editar, clonar, eliminar, activar o desactivar rutas. La lista IPv6 permite filtrar por dirección IP, Gateway IP o Interface, así como añadir, editar o eliminar rutas.

Administrative Distance y Metric

La Administrative Distance evalúa fuentes de routing que compiten entre sí. El valor más bajo tiene prioridad: se prefiere una ruta con 1 frente a una ruta con 5.

Si varias rutas estáticas al mismo destino tienen la misma Administrative Distance, decide la Metric. También en este caso se prefiere el valor más bajo.

La Route Precedence global entre Static, SD-WAN y VPN es un nivel distinto de Administrative Distance y Metric. No debe modificarse de forma precipitada por una sola ruta nueva.

Los valores de ejemplo 1 y 10 son puntos de partida sencillos para una sola ruta, no una recomendación general del producto. Antes de utilizarlos, se comparan las rutas existentes hacia el mismo destino. Para Primary/Backup o ECMP, se eligen deliberadamente Administrative Distance y Metric de acuerdo con la prioridad deseada.

Dos rutas con valores diferentes de Administrative Distance pueden definir una ruta preferida y otra secundaria. Sin embargo, Administrative Distance y Metric no supervisan por sí mismas el next hop. Para comprobar la disponibilidad se utiliza un gateway monitorizado en una ruta SD-WAN. Para seleccionar la ruta según latencia, jitter o pérdida de paquetes, también se necesita un SD-WAN Profile con Best quality o Custom SLA.

Configurar IPsec basado en rutas con dos conexiones a Internet ofrece un ejemplo completo con dos proveedores y dos túneles XFRM Any-to-Any. En él se validan conjuntamente gateways, rutas simétricas, Route Precedence, Failover y Failback.

Para IPv4 ECMP, se crean varias rutas al mismo destino con la misma Administrative Distance y Metric, pero con next hops distintos. Las conexiones pueden distribuirse entre next hops de coste equivalente; no se crea una ruta Primary/Backup basada en la calidad.

Usar Blackhole de forma deliberada

Con Blackhole, el firewall descarta el tráfico hacia el destino indicado sin responder al origen. Puede ser útil para redes bloqueadas o resumidas de forma intencionada, pero no sustituye a un next hop normal.

Si se redistribuyen rutas estáticas mediante RIP, OSPF o BGP, las rutas Blackhole deben filtrarse de forma específica. De lo contrario, el firewall también puede anunciar esta ruta de bloqueo a otros routers.

Casos especiales de IPv6 y túneles

En IPv6 unicast route se introducen la dirección de destino con prefijo, Gateway IP, Interface y Metric. Sophos no documenta para el formulario IPv6 ninguna Administrative Distance, opción Blackhole, descripción, función Clone ni función de activación o desactivación. Por tanto, la configuración IPv4 no debe aplicarse a IPv6 sin comprobarla.

Para una red IPv6 con routing normal, se siguen estos pasos:

En Routing > Static routes > IPv6 unicast route, hacer clic en Add.
Introducir una red de destino como 2001:db8:20::/64.
Introducir 2001:db8:4::2 en Gateway IP y seleccionar Port4 en Interface.
Elegir una Metric como 10 tras comparar las rutas existentes y guardar con Save.

El ejemplo presupone 2001:db8:4::1/64 en Port4 y un router directamente accesible en 2001:db8:4::2. Todas las direcciones IPv6 son valores de documentación y deben sustituirse conjuntamente por el plan de direccionamiento propio. Antes del cambio, registrar los valores anteriores de las rutas y asegurar un acceso de administración independiente. Después, comprobar 2001:db8:20::10 mediante Route lookup, una conexión real de cliente IPv6 y Packet capture con host 2001:db8:20::10; el tráfico saliente y las respuestas deben seguir la ruta prevista. También se necesitan una regla de firewall IPv6 y una ruta de retorno a la red de clientes. La excepción RED/ARP indicada más abajo no demuestra que IPv6 utilice el mismo mecanismo; confirmar cualquier caso especial de RED con IPv6 para el build instalado antes del cambio.

En un túnel IPsec basado en rutas con Any-to-Any Subnets, la ruta puede apuntar directamente a la interfaz XFRM sin necesitar un gateway separado. Si el túnel utiliza Traffic Selectors concretos, SFOS crea la ruta automáticamente; en ese caso no se configuran direcciones IP propias ni rutas adicionales en la interfaz XFRM. Una ruta XFRM tampoco es el caso especial de CLI ipsec_route, que depende de la versión; Crear una ruta IPsec en Sophos Firewall explica la diferencia.

Para una red detrás de la interfaz del peer de un túnel RED Site-to-Site entre Sophos Firewalls, se aplica otra excepción: se introduce como gateway la IP de la interfaz RED del peer, pero no se selecciona ninguna interfaz. Así, el firewall puede determinar mediante ARP la interfaz accesible. Configurar Site-to-Site RED entre dos Sophos Firewall explica el diseño completo de servidor y cliente.

Regla de firewall, NAT y ruta de retorno

El routing determina la ruta. La regla de firewall decide si el paquete puede pasar y NAT modifica sus direcciones cuando es necesario. Estas tres tareas se configuran por separado.

Para el ejemplo se necesita una regla desde la red de clientes 10.10.0.0/24 hasta la red de destino 10.20.0.0/24. La Destination Zone es la zona de Port4. La regla se limita a los servicios realmente necesarios y se activa el logging para la prueba.

En una red de sede con routing normal, generalmente no se desea SNAT porque el equipo remoto debe ver la IP real del cliente. El router 192.0.2.2 necesita entonces esta ruta de retorno:

Red de destino: 10.10.0.0/24
Next Hop: 192.0.2.1

Si no se puede configurar una ruta de retorno en el equipo remoto, SNAT puede ayudar desde el punto de vista técnico. Sin embargo, oculta la IP original del cliente y debe seguir siendo una decisión de diseño deliberada. Entender NAT en Sophos Firewall explica cómo interactúan estos elementos.

Rutas estáticas mediante la API XML: campos y límites de edición

Al automatizar rutas estáticas, hay que distinguir los campos XML bajo UnicastRoute de las etiquetas de la interfaz. Las tablas de parámetros de la API para SFOS 22.0 y 23.0 documentan lo siguiente:

Distance designa la Metric, no la Administrative Distance: opcional, valor predeterminado 0, rango 0–255.
AdministrativeDistance designa la Administrative Distance: opcional, valor predeterminado 1, rango 1–255.

Estos valores predeterminados de la API no son una recomendación para la ruta mostrada arriba ni demuestran que los campos omitidos permanezcan sin cambios durante una actualización. La prioridad deseada debe seguir comparándose con las rutas existentes.

El ejemplo XML también contiene OldConfiguration con los campos anteriores de destino, gateway, interfaz y prioridad. Sin embargo, la tabla de parámetros no describe este bloque. Por tanto, el ejemplo no demuestra qué campos identifican la ruta que se va a editar, qué valores anteriores son obligatorios ni si los cambios concurrentes se detectan o se cotejan de forma atómica. La automatización no debe basarse en este ejemplo para garantizar la correspondencia en las actualizaciones ni el control de concurrencia.

El ejemplo y la tabla también presentan inconsistencias en los campos de dirección:

IPFamily: el ejemplo muestra IPv4/IPv6, mientras que la tabla indica el tipo de datos INTEGER y el valor predeterminado IPv4.
DestinationIP: la descripción menciona direcciones IPv4/IPv6, pero el tipo de datos es IPADDRESS6.
Netmask: el ejemplo muestra 0.0.0.0, mientras que la tabla describe un prefijo de tipo INTEGER en el rango 0–128.

No se puede deducir de ello una solicitud IPv4/IPv6 universal y ejecutable. Antes de editar mediante la API en producción, aclarar y verificar en un entorno de pruebas el esquema de la solicitud y la correspondencia inequívoca con la ruta existente para el build instalado. Registrar previamente los valores anteriores y asegurar un acceso de administración independiente. Después, comprobar los valores de ruta guardados, Route Lookup y una conexión real de cliente, incluida su ruta de retorno; el rollback descrito más abajo sigue siendo necesario. Mientras el esquema o la correspondencia no estén claros, realizar el cambio mediante el procedimiento de la interfaz descrito arriba, en lugar de utilizar una solicitud XML basada en suposiciones.

La eliminación tiene sus propios límites de documentación. Las tablas de Delete Unicast Route para SFOS 22.0 y 23.0 señalan DestinationIP y Netmask como campos obligatorios. Sin embargo, esto no demuestra que constituyan un selector completo e inequívoco de la ruta que se va a eliminar. Las diez celdas de valores predeterminados están vacías; de ello no se deduce un valor 0, ni «sin cambios» ni null. Para IPFamily solo se indica el tipo de datos INTEGER, sin correspondencia entre los valores permitidos e IPv4 o IPv6. No se incluye ningún ejemplo de solicitud Delete.

Por tanto, los valores predeterminados de Add y Update descritos arriba y las suposiciones sobre OldConfiguration no deben trasladarse a Delete. Mientras no estén claros el esquema de la solicitud y la identificación inequívoca de la ruta de destino para el build instalado, se debe utilizar el procedimiento de la interfaz para eliminarla y el rollback descrito más abajo, no una solicitud de eliminación XML basada en suposiciones. Antes, se registran los valores anteriores de las rutas y se asegura un acceso de administración independiente; después, se comprueban los valores de las rutas, Route Lookup y una conexión real de cliente, incluida su ruta de retorno.

Comprobar la ruta

Una ruta guardada solo se considera validada cuando un cliente real alcanza el equipo remoto y funciona la ruta de retorno.

Las comprobaciones CLI siguientes se ejecutan en 4. Device Console, no en Advanced Shell, y solo consultan el estado actual. Antes de ejecutarlas, comprobar la sintaxis completa en el build instalado con Tab o ?. No ejecutar comandos incompletos: pueden hacer que el servicio access_server deje de responder.

Introducir 10.20.0.10 en Diagnostics > Tools > Route lookup. La salida debe mostrar Port4.
En Device Console, comprobar las rutas IPv4 o IPv6 configuradas y, si existe competencia con SD-WAN o VPN, la Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Iniciar desde el cliente 10.10.0.10 una conexión real con 10.20.0.10, por ejemplo ping o TCP 443, de acuerdo con la regla de firewall.
En Log viewer, comprobar el origen, el destino, el servicio, el Firewall Rule ID y un posible NAT Rule ID.
En Diagnostics > Packet capture, utilizar host 10.20.0.10 para comprobar si las solicitudes salen por Port4 y las respuestas regresan.

Si Route Lookup muestra la ruta correcta pero no fluye tráfico, la causa suele estar en la regla de firewall, NAT, la ruta de retorno o el sistema de destino. La prueba completa del flujo de paquetes se explica en Probar una regla de Sophos Firewall con Log Viewer y Packet Capture.

Para problemas de routing más profundos, resultan útiles las últimas entradas de los logs de unicast y kernel en Device Console:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log corresponde a las rutas unicast estáticas; zebra.log muestra la instalación de rutas unicast IPv4 estáticas en el kernel. Servicios y archivos de log de Sophos Firewall asigna otros archivos de log a los servicios responsables.

Después de reiniciar una interfaz o un túnel, una ruta basada solo en gateway puede no aparecer inicialmente en la tabla de routing. Aparece en cuanto el tráfico adecuado coincide con el destino y el gateway, y el firewall selecciona la interfaz. Por tanto, la ausencia de una entrada inmediatamente después del reinicio todavía no demuestra que exista un error.

Delimitar errores y ejecutar un rollback

Route Lookup muestra la interfaz equivocada

Comprobar la dirección de destino y el prefijo; un error tipográfico puede coincidir con otra red.
El gateway debe ser directamente accesible mediante la interfaz seleccionada.
Comparar las rutas estáticas competidoras, así como Administrative Distance y Metric.
Para SD-WAN o VPN, comprobar el orden actual con system route_precedence show. Cambiar Route Precedence de forma segura explica el cambio global.

La solicitud sale, pero no regresa ninguna respuesta

Comprobar la ruta de retorno en el siguiente router y en el sistema de destino.
Comprobar la regla de firewall para la dirección iniciadora y las reglas NAT existentes. Solo se necesita una regla en la dirección opuesta si el equipo remoto inicia nuevas conexiones.
Utilizar Packet Capture para determinar si la respuesta regresa a Port4.
Comprobar el firewall local y el gateway predeterminado del sistema de destino.

Rollback seguro

Una ruta IPv4 nueva se desactiva primero en lugar de eliminarse. A continuación, se vuelven a comprobar Route Lookup, una nueva conexión de cliente y la ruta anterior. Solo cuando se haya confirmado el estado inicial deben eliminarse, si es necesario, la ruta y las reglas u objetos NAT creados exclusivamente para este cambio.

Sophos no documenta una función de activación o desactivación para IPv6. Por eso, los valores anteriores se registran previamente y la ruta nueva se modifica o elimina durante un rollback. En un clúster HA, se repite la prueba end-to-end en el nuevo Primary después de un failover.