Configurar y probar DHCP Relay en Sophos Firewall

Un relé DHCP reenvía las solicitudes DHCP desde una red de clientes a un servidor situado en otra red. En Sophos Firewall, se abre Network > DHCP, se añade un agente para la interfaz de clientes en Relay y se introduce la dirección IP del servidor DHCP.

Procedimiento resumido: Seleccionar la interfaz de clientes, introducir el servidor DHCP, comprobar en el servidor el scope correspondiente y la ruta de retorno, renovar el lease y capturar el intercambio con port 67 or port 68. Relay through IPsec solo se activa con IPsec policy-based, no con una VPN route-based. Para una VPN route-based, aclarar primero con Sophos Support las contradicciones entre las fuentes descritas más abajo y la compatibilidad de la compilación exacta; este procedimiento resumido no constituye una aprobación de esa configuración.

El ejemplo utiliza la red de clientes 10.20.0.0/24, la interfaz de relé 10.20.0.1 y el servidor DHCP 172.16.16.17. Es un ejemplo IPv4: adaptar todas las direcciones, la interfaz de clientes y el nombre a la red propia. El scope es el rango de direcciones, junto con los parámetros de red, del que el servidor asigna leases. El gateway debe estar en la red de clientes y ser accesible; el servidor DNS debe ser accesible desde el cliente. Antes del cambio, guardar una copia de los scopes, agentes de relé y rutas existentes, y utilizar un cliente de prueba que obtenga direcciones automáticamente mediante DHCP.

Requisitos y limitaciones

El servidor DHCP debe tener un scope para 10.20.0.0/24. Sophos Firewall no concede el lease; utiliza la dirección de la interfaz de relé para que el servidor seleccione el scope correcto.

El relé necesita una ruta al servidor y el servidor una ruta de retorno a 10.20.0.1.

Si el firewall debe distribuir direcciones directamente en la red de clientes conectada, se debe usar Configurar Sophos Firewall como servidor DHCP. Las opciones DHCP se configuran en el servidor que concede el lease.

También es posible utilizar un servidor DHCPv4 y un relé en el mismo Sophos Firewall:

• El servidor escucha en otra interfaz.
• Accept client request via relay está activado.
• Cada subred de clientes tiene su propio scope de servidor con el rango de leases, la máscara de subred, el gateway y el DNS correspondientes.

El agente de relé utiliza la interfaz de clientes correspondiente y, como destino, la dirección de la interfaz del servidor. Para los clientes de la subred del servidor se mantiene la asignación directa sin relé.

Un servidor DHCPv6 y un DHCPv6 Relay no pueden estar activos al mismo tiempo. Si el firewall debe distribuir por sí mismo las direcciones IPv6, Configurar un servidor DHCPv6 en Sophos Firewall explica el procedimiento separado con Router Advertisement, DUID y comprobación del lease.

Se aplican las siguientes limitaciones:

• La interfaz de relé debe estar en la misma subred que los clientes y no puede ser la interfaz del servidor DHCP.
• Los agentes de relé pueden utilizar interfaces físicas y virtuales como VLAN, Wireless o Bridge, pero no un Interface Alias.
• No se crea un agente de relé en la subred del servidor DHCP.
• Se crea un agente de relé independiente para cada subred de clientes.
• En cada agente de relé pueden añadirse hasta ocho servidores DHCP. La solicitud se envía a todos y el cliente utiliza la primera oferta.
• Un servidor DHCPv4 y un relé DHCPv4 pueden funcionar en el mismo firewall, pero no en la misma interfaz.
• Un servidor DHCPv6 y un relé DHCPv6 no pueden estar activos al mismo tiempo en el mismo firewall.
• El cliente y el relé utilizan UDP 67 y 68; el relé y el servidor se comunican mediante UDP 67. El servidor necesita una ruta de retorno a la IP de relé 10.20.0.1.

Varios destinos de relé deberían entregar parámetros de red y opciones coherentes al mismo cliente, pero con una asignación de direcciones coordinada mediante failover de servidores según la documentación del servidor, o con rangos de asignación dinámica que no se solapen. De lo contrario, las respuestas distintas provocan un comportamiento difícil de reproducir.

Configurar DHCP Relay sin VPN

1. Abrir Network > DHCP.
2. En Relay, hacer clic en Add.
3. Introducir un nombre único, como relay-clients-vlan20.
4. Para este ejemplo, seleccionar IPv4 en IP version. Para IPv6, no utilizar las direcciones IPv4 ni los puertos UDP de esta guía.
5. En Interface, seleccionar la interfaz de clientes VLAN20 - 10.20.0.1.
6. En DHCP server IP, introducir el servidor 172.16.16.17, añadirlo a la lista con el botón de signo más y comprobar que aparece en ella.
7. Dejar Relay through IPsec desactivado y guardar.

A continuación, renovar un lease desde un cliente de prueba. Las solicitudes de relé son tráfico generado por el sistema, por lo que este procedimiento no necesita una regla dedicada en el firewall de relé. Los dispositivos entre el relé y el servidor deben permitir UDP 67 en ambos sentidos; el segmento de clientes utiliza UDP 67/68. Si el cliente no recibe una dirección, comprobar primero que el servidor tenga un scope para 10.20.0.0/24 y conozca una ruta a la interfaz de relé. Para problemas de VLAN, consulte Configurar una interfaz VLAN en Sophos Firewall.

API XML: identidad y límite de validación de IPv6

En la automatización, esta misma configuración corresponde al objeto DHCPRelay: Name identifica al agente de relé, Interface a la interfaz de clientes, IPFamily a la familia elegida expresamente, IPv4 o IPv6, y DHCPServerIP a la lista de servidores. La documentación de Add/Edit para SFOS 22 y 23 marca estos cuatro campos como obligatorios; el valor predeterminado documentado de IPFamily es IPv4. DHCPServerIP se describe como un ARRAY con IPADDRESS e IPADDRESS6: se permiten varios valores, se ignoran los duplicados y se excluye LINKLOCAL. Por tanto, siguen siendo posibles varios destinos de relé; el único campo de marcador de posición del ejemplo no demuestra ni la serialización de la lista ni una codificación de IPv6. Mantener de forma deliberada el estado de Relay through IPsec que corresponda a la variante de VPN explicada más abajo, sin deducirlo de un ejemplo de la API.

Al mismo tiempo, la tabla de parámetros indica un máximo de 15 caracteres para DHCPServerIP. Este dato no concuerda de forma general con la representación permitida de direcciones IPv6 mediante IPADDRESS6: la documentación es inconsistente en este punto y no demuestra cómo procesa IPv6 el validador de la compilación concreta. De ello no se deduce que el producto no admita DHCPv6 Relay, ni una codificación alternativa, ni permiso para acortar las direcciones.

Para IPv6, utilizar primero la configuración manual en WebAdmin y, antes de automatizar IPv6, aclarar con Sophos Support el esquema, la validación de direcciones y el formato de la lista de servidores para la versión y la compilación exactas de SFOS. Una configuración guardada en la GUI o un lease obtenido correctamente por un cliente no confirma que una solicitud XML de IPv6 sea válida. Siguen siendo necesarias las comprobaciones del cliente y del flujo de paquetes, así como el rollback basado en el estado previo que se describen más abajo; las direcciones IPv4 y los puertos UDP de este ejemplo no se trasladan a IPv6.

Cambiar el intervalo de actualización de Relay solo de forma controlada

Device Console muestra el intervalo global de los paquetes de actualización de DHCP Relay con:

system dhcp dhcp-relay-refresh-interval show

El valor predeterminado documentado es de 10 segundos. Sophos indica dos límites superiores distintos en la misma página de SFOS 22: la sintaxis muestra 10000, mientras que la descripción de la opción indica 1000 segundos. Por eso no se utiliza un valor superior a 1000 basándose únicamente en la línea de sintaxis. Cualquier necesidad excepcional debe confirmarse primero con Sophos Support.

El cambio utiliza esta plantilla:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

El marcador se sustituye por un valor comprobado. El intervalo no se modifica como ajuste general y no repara un scope de servidor ausente, routing, IPsec ni reglas de firewall. Primero se registra el valor actual; después se utilizan show, una nueva concesión de cliente y el flujo de paquetes UDP 67/68. El rollback restaura el valor consultado previamente.

DHCP Relay mediante IPsec route-based

La ayuda de SFOS-22 y SFOS-23 documenta DHCP Relay a través de XFRM hacia un servidor DHCP externo situado detrás del firewall central. La configuración descrita utiliza un túnel route-based Any-to-Any. Los Traffic Selectors route-based no están confirmados para este procedimiento.

⚠️ La ayuda oficial es contradictoria en SFOS 22 y SFOS 23: tanto la página general DHCP como Routing and NAT for IPsec tunnels indican que DHCP Relay no es posible a través de una VPN route-based. En cambio, Add a DHCP relay y la guía específica para route-based describen la configuración Any-to-Any siguiente. Esto no permite concluir que exista compatibilidad confirmada del producto. Si los campos son distintos, no recurrir a las opciones policy-based; aclarar la topología y la compilación exacta con Sophos Support.

⚠️ El conflicto entre las fuentes sigue sin resolverse; el diseño está documentado, pero no se ha confirmado ni probado como capacidad del producto. Antes de implementarlo, Sophos Support debe aclarar la compatibilidad del build exacto de SFOS y de la topología Any-to-Any con un servidor DHCP externo. Esa confirmación es un requisito previo, no una prueba de la que ya se disponga aquí. Hasta que se aclare, no se deben realizar cambios de configuración route-based siguiendo este procedimiento.

La configuración documentada incluye los siguientes requisitos. Hasta aclararlos con Sophos Support, estos detalles solo sirven para la planificación; los cambios de configuración se realizan únicamente después de obtener la confirmación:

1. Conexiones IPsec Any-to-Any en ambos firewalls.
2. Interfaces XFRM direccionadas y con gateway.
3. Rutas estáticas, SD-WAN o dinámicas en ambos firewalls: desde el relé hasta el servidor DHCP y, para la respuesta, de vuelta a la IP de relé 10.20.0.1.
4. Acceso IPsec permitido en Administration > Device access para las interfaces WAN implicadas.
5. Una regla en la sede central desde VPN hasta la zona del servidor con Source 10.20.0.1, Destination 172.16.16.17 y Service DHCP.

En la sucursal, se configura la interfaz de clientes como agente de relé; Relay through IPsec permanece desactivado. La solicitud del relé es tráfico generado por el sistema y no necesita una regla de firewall DHCP propia en esa ubicación.

Una ruta SD-WAN utiliza:

• Any como Source.
• El host 172.16.16.17 como Destination.
• DHCP como Service.
• El gateway XFRM remoto.

En la sede central, la ruta de retorno del servidor DHCP a la IP del relé 10.20.0.1 pasa por el gateway XFRM.

Para evitar que este tráfico se desvíe por otro gateway si falla el túnel, activar Route only through specified gateways en ambas rutas SD-WAN dedicadas.

Para crear las rutas SD-WAN dedicadas, después de obtener la confirmación:

1. Abrir Routing > SD-WAN routes, seleccionar IPv4 > Add y asignar un nombre único.
2. En Link selection settings, seleccionar Primary and backup gateways.
3. En Primary gateway, introducir el gateway XFRM correspondiente de cada firewall; después, guardar.

La regla de firewall de la sede central se crea en Rules and policies > Firewall rules > Add firewall rule > New firewall rule con los hosts y el Service mencionados anteriormente.

La Destination zone corresponde a la red real del servidor, por ejemplo, DMZ, y no es automáticamente LAN.

La opción Fail-closed impide el enrutamiento alternativo, pero también implica que, si falla el túnel, no se pueden obtener nuevos leases por esta ruta.

También deben existir las reglas VPN generales del túnel Any-to-Any. Configurar IPsec Site-to-Site en Sophos Firewall explica con detalle la configuración del túnel y las rutas XFRM.

⚠️ Este procedimiento route-based se aplica a un servidor DHCP externo situado detrás del firewall de la sede central. Este diseño no admite una interfaz de Sophos Firewall configurada como servidor DHCP central.

DHCP Relay mediante IPsec policy-based

Con IPsec policy-based, se activa Relay through IPsec en la sucursal. Las subredes locales y remotas de la conexión IPsec deben incluir la interfaz de relé y el servidor DHCP.

Si hay un servidor DHCP externo detrás del firewall central, se necesitan dos reglas en ese firewall.

Es imprescindible disponer de un túnel existente y operativo. Si hay que crearlo, se hace en Site-to-site VPN > IPsec > IPsec connections > Add con Connection type: Policy-based:

• En la sucursal, Gateway type: Initiate the connection.
• En la sede central, Respond only.
• Listening interface es la interfaz WAN propia de cada lado.
• Gateway address es la dirección WAN del otro extremo.

La autenticación y la Preshared key deben coincidir; las redes locales y remotas se invierten en el otro extremo. Para el ejemplo con servidor externo, son 10.20.0.0/24 y la red del servidor que se utilice realmente.

Permitir el acceso IPsec desde WAN en Administration > Device access.

En la sucursal, el tráfico de relé generado por el sistema no necesita una regla de firewall creada automáticamente. En la sede central, las reglas creadas automáticamente se pueden restringir a los hosts DHCP, las zonas y los Services indicados a continuación.

No eliminar las reglas existentes para el resto del tráfico VPN.

• VPN a la zona del servidor: red de relé al servidor DHCP, Service DHCP.
• Zona del servidor a VPN: servidor DHCP a la red de clientes, Service DHCP.

Para el procedimiento policy-based documentado, la dirección de origen del tráfico de relé generado por el sistema debe fijarse en la IP del relé mediante sys-traffic-nat.

Los siguientes comandos se ejecutan en Device Console después de iniciar sesión por SSH.

La ayuda específica de Routing/NAT para SFOS 22 y 23 distingue entre tráfico reenviado y tráfico generado por el sistema: para este último no se necesita ninguna system ipsec_route adicional.

En cambio, la página general de DHCP sigue mencionando un paso para la ruta IPsec. Esta diferencia no justifica crear otra ruta de forma rutinaria: primero, comprobar la ruta existente y el flujo de paquetes; si la compilación se comporta de otra manera, consultar con Sophos Support.

NAT no sustituye a una ruta.

• destination sigue siendo la dirección del servidor.
• snatip es la dirección de origen del relé, no la dirección del servidor.
• Una regla WAN-MASQ convencional no sustituye a sys-traffic-nat.

Registrar el estado actual antes de realizar el cambio:

show advanced-firewall

⚠️ sys-traffic-nat add modifica la configuración NAT global para el tráfico generado por el sistema. El destino y la dirección de origen deben coincidir con el túnel IPsec y la ruta de retorno.

Para este ejemplo, se establece la dirección de la interfaz de relé como dirección de origen hacia el servidor DHCP:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

A continuación, volver a ejecutar show advanced-firewall y comprobar que exista exactamente esta entrada. El servidor debe poder alcanzar 10.20.0.1 a través del túnel. Si la misma entrada ya existía antes del cambio, no forma parte del rollback de este procedimiento.

Para una entrada creada mediante este procedimiento, el rollback es:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Crear una IPsec Route en Sophos Firewall explica otros casos especiales de routing policy-based y los procedimientos para versiones anteriores de SFOS.

Cuando el firewall de la sede central es el servidor DHCP

Solo en este escenario policy-based, en el que Sophos Firewall de la sede central es el propio servidor DHCP, se deja desmarcado Create firewall rule en las conexiones IPsec de ambos firewalls. La comunicación DHCP con el servidor integrado en el firewall no equivale al reenvío hacia un servidor externo; las reglas de reenvío de la sede central descritas anteriormente corresponden al escenario con servidor externo. Se mantienen el acceso IPsec desde WAN en Administration > Device access y las reglas necesarias para el resto del tráfico de usuarios de la VPN.

Si el propio Sophos Firewall central actúa como servidor DHCP con IPsec policy-based:

1. Crear o editar un scope de servidor en Network > DHCP > Server.
2. Activar Accept client request via relay, introducir un rango de leases de 10.20.0.0/24 y establecer 10.20.0.1 como gateway.
3. En el agente de relé, introducir la dirección de la interfaz del servidor del firewall central como DHCP server IP; en el ejemplo NAT anterior, sustituir 172.16.16.17 por esa dirección.

Un ejemplo adaptable para Dynamic IP lease es de 10.20.0.10 a 10.20.0.30, con la máscara de subred 255.255.255.0. El gateway 10.20.0.1 y las direcciones fijas de infraestructura quedan fuera del pool.

Elegir el pool según el número de clientes y las direcciones ya reservadas.

Utilizar Use device’s DNS settings solo si los servidores DNS configurados allí son accesibles desde la sucursal.

Para este servidor interno del firewall, los selectores policy-based de la sede central utilizan la dirección de la interfaz del servidor y la red de clientes; en la sucursal se aplica la asignación inversa.

⚠️ Comprobar la versión antes de un cambio global: El siguiente procedimiento de activación solo se aplica al escenario documentado de SFOS 22. Las páginas de ayuda disponibles de SFOS 23 se contradicen: HO firewall as DHCP server and BO firewall as relay agent describe las concesiones DHCP mediante IPsec como activadas de forma predeterminada y sin configuración adicional; la página general DHCP sigue indicando que deben activarse mediante la CLI. El conflicto sigue sin resolverse. No confirma el estado real tras una actualización ni demuestra que el comando se haya eliminado. En SFOS 23, no activar rutinariamente la opción global: registrar el build exacto y el estado actual, y confirmar primero con Sophos Support si es necesario un cambio. Si el estado no está claro o el comando de estado no está disponible, detenerse antes de realizar cambios.

Registrar el build exacto de SFOS y, antes de cualquier cambio, mostrar y guardar el estado actual en la Device Console del firewall central que concede los leases:

system dhcp lease-over-IPSec show

⚠️ La siguiente opción se aplica globalmente a los leases DHCP mediante IPsec. Solo debe activarse en el firewall que concede los leases. Anote el estado inicial mostrado para que el rollback no desactive una configuración preexistente.

Solo en SFOS 22, si el estado registrado es desactivado, activarla y comprobarla después con el comando show anterior. Si ya está activada, no realizar cambios:

system dhcp lease-over-IPSec enable

Solo si la función estaba desactivada en el firewall central que concede los leases y se activó realmente durante el procedimiento autorizado, el rollback es:

system dhcp lease-over-IPSec disable

Si ya estaba activada, se deja activada. En ambos casos, system dhcp lease-over-IPSec show confirma el estado restaurado.

Probar la configuración y solucionar errores

Un agente de relé guardado no demuestra por sí solo que la configuración funcione. Se renueva el lease desde un cliente de prueba y se establece un filtro preciso en Diagnostics > Packet capture > Configure, en el campo Enter BPF string:

port 67 or port 68

En el flujo de paquetes deberían verse, en este orden:

1. La solicitud del cliente.
2. La solicitud reenviada.
3. El Offer del servidor.
4. La ruta de retorno.

Las columnas In interface, Out interface, Source IP, Destination IP, Ports [src, dst] y Status muestran dónde se interrumpe el intercambio.

Los paquetes del relé pueden aparecer como Generated o Forwarded. Si aparece Violation, Reason proporciona la siguiente pista para la comprobación.

Packet Capture en Sophos Firewall WebAdmin explica el uso y los campos.

Un Offer por sí solo no basta: el cliente debe solicitar la dirección y recibir un ACK.

Después, comprobar en el cliente la dirección IP del pool previsto, la máscara de subred, el gateway y el DNS, y revisar la entrada del lease en el servidor que lo concede.

Una respuesta al ping del servidor no demuestra ni la accesibilidad por UDP ni que el intercambio DHCP se haya completado correctamente.

Estas comprobaciones debe realizarlas el administrador.

Las siguientes comprobaciones permiten delimitar los errores habituales:

• No se ve ninguna solicitud del cliente: Comprobar la VLAN, el puerto del switch, la interfaz de clientes o el cliente DHCP local.
• La solicitud llega al firewall, pero no se reenvía: Comprobar la interfaz de relé, la IP del servidor, la ruta y, con IPsec policy-based, Relay through IPsec.
• El servidor recibe la solicitud, pero no responde: Comprobar el scope para la subred del relé, la autorización del servidor y el firewall local del servidor.
• El Offer llega a la sede central, pero no al cliente: Comprobar la ruta de retorno, las reglas del firewall central, las subredes IPsec y la entrada NAT.
• El cliente recibe una configuración incorrecta: Identificar qué servidor responde primero y comparar los scopes y las opciones DHCP en todos los destinos del relé.
• Policy rule denied con Source 0.0.0.0: Un cliente sin dirección comienza con esta dirección de origen. Comprobar si un servidor DHCP o un relé atiende la interfaz de clientes correcta; no crear una regla Allow general para 0.0.0.0 o Any con el fin de ocultar el síntoma. La página general describe el descarte cuando no hay servidor; en el escenario de relé, comprobar el recorrido real de los paquetes en lugar de deducir una prohibición general del relé.

Revertir la configuración

Para un rollback planificado, primero hay que comprobar que los clientes puedan alcanzar otro servidor DHCP. Después se elimina el agente de relé en Network > DHCP > Relay. Las rutas, los objetos de host y las reglas dedicados solo se eliminan cuando Packet Capture ya no muestra solicitudes de relé; se conservan los objetos compartidos con otro tráfico VPN. Con IPsec policy-based, solo se elimina además la entrada sys-traffic-nat creada mediante este procedimiento. Se restaura lease-over-IPSec únicamente en el firewall central que concede los leases y solo si su estado se modificó realmente durante el procedimiento autorizado; se recupera el estado anotado previamente. Esto no forma parte del rollback de un relé hacia un servidor DHCP externo ni de un estado que no se haya modificado.

Preguntas frecuentes