Cómo configurar Sophos Firewall como servidor DHCP

Sophos Firewall puede distribuir directamente a los clientes direcciones IPv4, la puerta de enlace, servidores DNS y otros ajustes de red. Para ello, se crea en Network > DHCP un servidor para la interfaz de los clientes, se define el rango de direcciones y después se comprueba si el cliente recibe una concesión adecuada.

Procedimiento rápido: Abrir Network > DHCP > Server > Add, seleccionar la interfaz y el rango de direcciones, activar Use interface IP as gateway, configurar cuidadosamente los ajustes DNS y guardar. A continuación, comprobar el servicio DHCP server en System services > Services y verificar la dirección asignada en IPv4 lease.

Esta guía aborda un servidor DHCPv4 para clientes de una red conectada directamente. Si un servidor DHCP central debe atender otra subred, consulta Configurar y probar DHCP Relay en Sophos Firewall. Los valores para PXE, VoIP y específicos de fabricante se describen en Configurar opciones DHCP en Sophos Firewall.

En IPv6, la asignación de direcciones y la puerta de enlace tienen funciones diferentes. El procedimiento completo se explica en Configurar y probar un servidor DHCPv6 en Sophos Firewall.

Ejemplo y planificación de direcciones

El ejemplo utiliza una VLAN de clientes con estos valores:

Interfaz: VLAN20 - 10.20.0.1/24
Rango dinámico: 10.20.0.100 a 10.20.0.199
Puerta de enlace: 10.20.0.1
Asignación estática para una impresora: 10.20.0.20
Servidores DNS internos: 10.10.0.10 y 10.10.0.11
Domain Name: corp.example

El rango dinámico se encuentra dentro de la red de la interfaz, pero no contiene la dirección de red, la dirección de broadcast ni la puerta de enlace. En este ejemplo, las direcciones inferiores a 10.20.0.100 quedan reservadas para la infraestructura y las asignaciones estáticas. De este modo, el rango DHCP no asigna dinámicamente las direcciones reservadas. Sin embargo, esta separación no protege frente a otro dispositivo que tenga configurada manualmente la misma dirección IP.

Antes de activarlo, se debe comprobar qué direcciones ya utilizan los switches, puntos de acceso, impresoras o servidores. Si todavía funciona otro servidor DHCP en la misma VLAN, primero debe decidirse qué servidor será responsable en el futuro. Dos servidores sin coordinar pueden distribuir puertas de enlace o servidores DNS diferentes y provocar errores intermitentes.

La propia interfaz ya debe tener la dirección IP estática correcta. Configurar una interfaz VLAN en Sophos Firewall explica cómo se relacionan la interfaz, la zona y la VLAN.

Configurar el servidor DHCP

⚠️ En un clúster HA, Sophos admite el servicio DHCP en modo Active-passive, pero no en modo Active-active. Comprobar este requisito antes de crear el servidor DHCP; cambiar el modo HA no es un paso de resolución de problemas para un único ámbito.

Abrir Network > DHCP.
En Server, hacer clic en Add.
Introducir un nombre inequívoco, como dhcp-vlan20-clients.
En Interface, seleccionar la interfaz de clientes VLAN20 - 10.20.0.1.
En Dynamic IP lease, añadir el rango 10.20.0.100 a 10.20.0.199.
Introducir 255.255.255.0 como Subnet mask para la red /24 del ejemplo.
Activar Use interface IP as gateway. Los clientes reciben entonces 10.20.0.1 como Gateway.
Definir los servidores DNS, el Domain name y los tiempos de concesión de acuerdo con la red.
Añadir asignaciones estáticas MAC-IP si es necesario.
Guardar con Save.

Para los clientes conectados directamente, la interfaz seleccionada determina en qué red responde el firewall a las solicitudes DHCP. Por tanto, el rango dinámico debe corresponder a la subred de esta interfaz. Los servidores DHCP pueden configurarse en interfaces físicas, VLAN, Wireless y Bridge, pero no en un Interface Alias. No se puede configurar al mismo tiempo un servidor DHCPv4 en una interfaz que ya se utiliza como DHCP Relay.

Para los clientes conectados directamente, se deja desactivado Accept client request via relay. Esta opción solo se necesita cuando la configuración del servidor debe aceptar, mediante un agente de retransmisión DHCP, solicitudes procedentes de una subred de clientes remota. Cada red remota necesita una configuración de servidor adecuada con su propia puerta de enlace; el diseño completo se explica en la guía de DHCP Relay.

Estas configuraciones de servidor pueden compartir la misma interfaz DHCP en la que el servidor recibe las solicitudes reenviadas. Hay que distinguir la interfaz de escucha de la subred remota de clientes: el rango de direcciones, la máscara de subred y la puerta de enlace de cada configuración pertenecen a su red de clientes. El servidor asigna direcciones de la subred de la dirección de origen del agente de retransmisión; compartir una interfaz de escucha no sustituye, por tanto, una configuración independiente para cada red de clientes.

Elegir correctamente la puerta de enlace y DNS

En una red de clientes normal, la dirección IP de Sophos Firewall en esta interfaz es la puerta de enlace. Por eso, en el ejemplo los clientes reciben 10.20.0.1.

Con Use device’s DNS settings, el firewall distribuye a los clientes sus servidores DNS configurados. Esta opción es adecuada si esos servidores pueden resolver tanto nombres públicos como los nombres internos necesarios. En un entorno AD, normalmente se introducen los servidores DNS internos para que los controladores de dominio, los servicios internos y los dominios de búsqueda funcionen de forma fiable. Por lo general, los servidores DNS públicos por sí solos no son suficientes.

Domain name entrega un sufijo DNS al adaptador de red. Con corp.example, por ejemplo, el cliente puede completar el nombre de host fileserver como fileserver.corp.example. Esto no sustituye ni un registro DNS ni un servidor DNS accesible; ambos deben comprobarse por separado.

Si los clientes reciben la dirección IP del firewall como servidor DNS, Sophos Firewall puede reenviar las solicitudes de determinadas zonas internas a los servidores responsables. Este caso se explica en Configurar DNS Request Routes en Sophos Firewall. Sin embargo, si DHCP distribuye directamente las direcciones de otros servidores DNS, las solicitudes de los clientes no pasan por las Request Routes del firewall.

Los campos WINS server 1 y WINS server 2 solo están destinados a entornos NetBIOS antiguos. Deben dejarse vacíos mientras ningún cliente ni aplicación necesite un servicio WINS. Si todavía se utiliza WINS, se introducen las direcciones reales de los servidores y se comprueba la resolución de nombres con un cliente afectado.

Definir tiempos de concesión adecuados

Default lease time es el tiempo de concesión normal que se entrega al cliente. Max lease time es el límite máximo; cuando finaliza, el cliente debe enviar una nueva solicitud al servidor DHCP. Ambos valores se indican en minutos.

Las concesiones más largas resultan adecuadas en redes estables de oficina o de dispositivos, ya que los equipos cambian con poca frecuencia. En redes inalámbricas de invitados, formación o con muchos cambios, una concesión más corta evita que los dispositivos que ya no están conectados ocupen el rango durante mucho tiempo.

En cambio, las concesiones muy cortas generan renovaciones innecesarias. Por tanto, no existe un valor ideal general: lo decisivo es el tamaño del rango y la frecuencia con la que cambian los clientes.

Conflict detection comprueba una dirección antes de asignarla y ayuda a detectar direcciones IP que ya están en uso. Esta función resulta especialmente útil si todavía existen dispositivos configurados manualmente o un direccionamiento antiguo que no está documentado por completo.

Crear una asignación estática IP-MAC

Una asignación estática garantiza que un dispositivo concreto reciba siempre la misma dirección mediante DHCP. Es útil para impresoras, puntos de acceso u otros dispositivos que deben seguir accesibles, pero que también deben recibir valores configurados de forma centralizada, como la puerta de enlace y DNS.

En Static IP MAC mapping, se introducen el nombre de host, la dirección MAC y la dirección IP deseada. En el ejemplo, la impresora con su dirección MAC real recibe siempre 10.20.0.20. Esta dirección se encuentra deliberadamente fuera del rango dinámico.

Una asignación DHCP no es lo mismo que una dirección IP configurada manualmente en el dispositivo: el dispositivo sigue siendo un cliente DHCP, pero el firewall reserva la concesión correspondiente. Si un portátil o un smartphone utiliza una dirección MAC inalámbrica privada o aleatoria, la asignación debe corresponder a la dirección MAC que el dispositivo utiliza realmente en esa red inalámbrica.

Una misma dirección MAC puede recibir como máximo cinco direcciones IP estáticas, siempre que se encuentren en subredes diferentes. Una asignación normal en una sola red no necesita la configuración global.

En SFOS 23, cuando la misma dirección MAC está vinculada en varias configuraciones de servidor DHCP, se establece Lease scope for static binding en Global en Network > DHCP > Advanced server settings. Los clientes pueden obtener una dirección de cualquier servidor DHCP configurado en el firewall, independientemente de dónde esté configurada la vinculación IP-MAC estática. Network lo limita al servidor que contiene la vinculación. Primero se anota el valor anterior y después se prueba cada ámbito afectado con una concesión nueva. Para revertir, se restablece exactamente el valor anotado.

SFOS 22: vinculación global mediante Device Console

Antes de modificar la asignación global, tras iniciar una sesión SSH, se consulta en Device Console la ayuda local específica de los comandos conf-generation-method y static-entry-scope en la versión de SFOS instalada. Se determinan y registran el método y el ámbito actuales mediante una consulta de solo lectura admitida en esa versión o una visualización disponible en la interfaz de usuario; también se comprueba previamente la sintaxis correspondiente para revertir el cambio. Aquí no se confirma que una forma de show sea válida para todas las versiones. Si no se pueden determinar de forma fiable el estado inicial o el procedimiento de reversión, no se realiza ningún cambio y primero se aclara el estado con el soporte técnico.

A continuación, se modifican únicamente los valores que difieren del estado de destino necesario:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

El ajuste afecta a todas las configuraciones de servidor DHCP. No es necesario para asignaciones normales que solo aparecen una vez, por lo que únicamente debe modificarse para este caso con varios ámbitos.

Cuando una dirección MAC está vinculada más de una vez, el estado de destino mostrado arriba es importante para que los clientes reciban los datos DHCP correctos, como los servidores DNS y la puerta de enlace. No se debe sobrescribir un estado que ya sea adecuado ni asumir valores predeterminados como estado inicial. Para revertir el cambio, se restauran exactamente los valores registrados previamente con la sintaxis confirmada para la versión instalada. Si los valores iniciales eran realmente network y old, pueden utilizarse system dhcp static-entry-scope network y system dhcp conf-generation-method old, siempre que la ayuda local confirme estas formas. Después se comprueba cada ámbito afectado con una nueva concesión de cliente.

Comprobar el servicio y probar la concesión

Después de guardar, se comprueba en System services > Services que DHCP server esté en ejecución. Si el servicio está detenido, se inicia desde ese mismo lugar.

A continuación, se conecta un cliente de prueba controlado a la VLAN correcta. En Windows, se puede solicitar y comprobar una nueva concesión de esta forma:

⚠️ ipconfig /release interrumpe la conexión IPv4 actual. No se debe ejecutar el comando a través de esa misma conexión remota si no existe un acceso alternativo.

ipconfig /release
ipconfig /renew
ipconfig /all

El cliente debe recibir una dirección entre 10.20.0.100 y 10.20.0.199, la puerta de enlace 10.20.0.1 y los servidores DNS previstos. En Network > DHCP > IPv4 lease, el firewall muestra la dirección asignada con las horas de inicio y finalización, la dirección MAC y el nombre de host.

Como mínimo, deben cumplirse estas comprobaciones:

El cliente recibe una dirección del rango correcto.
La puerta de enlace y los servidores DNS coinciden con la planificación.
La puerta de enlace es accesible.
Se resuelven los nombres internos y externos.
El cliente solo puede acceder a las redes y servicios que permite su regla de firewall.

No se recibe ninguna dirección o se recibe una incorrecta

Si el cliente no recibe ninguna concesión, primero se comprueban la interfaz, la VLAN y el estado del servicio. Estos errores son especialmente frecuentes:

Interfaz incorrecta: El servidor DHCP no está asignado a la interfaz de la red de clientes.
La VLAN no llega al firewall: El enlace ascendente del switch no permite la VLAN etiquetada o el puerto del cliente está asignado incorrectamente.
El rango de direcciones no coincide: La dirección inicial o final está fuera de la subred de la interfaz.
El rango está agotado: Comparar el número y la duración de las concesiones ocupadas con el tamaño del rango configurado. La lista de concesiones muestra las direcciones asignadas, pero no ofrece una lista propia de direcciones libres.
Responde otro servidor DHCP: El cliente recibe una dirección, pero una puerta de enlace o unos servidores DNS incorrectos.
Policy rule denied para el origen 0.0.0.0: Si no se ha configurado ni un servidor DHCP ni un relay en la interfaz, una solicitud del cliente puede descartarse con esta entrada. Por tanto, el mensaje no demuestra que la causa sea una regla de firewall normal. Primero se comprueban el servidor DHCP, el relay y la asignación de la interfaz.
Se necesita DHCP Relay: El cliente no se encuentra en una red conectada directamente al servidor.
La asignación estática no se aplica: La dirección MAC introducida no corresponde a la dirección MAC que realmente utiliza el cliente.

Una captura de paquetes filtrada por port 67 or port 68 permite ver si se intercambian mensajes Discover, Offer, Request y ACK, así como qué servidor responde. Usar Packet Capture en el WebAdmin de Sophos Firewall explica el funcionamiento de la herramienta.

Si un Discover llega al firewall pero no se produce ningún Offer, también se comprueban el estado de dhcpd y el registro dhcpd.log. Los comandos y las rutas de registro correspondientes se describen en Comprobar servicios y registros de Sophos Firewall mediante CLI.

Si el cliente recibe una dirección IP correcta, pero no puede resolver nombres, primero se comprueban las direcciones DNS distribuidas mediante DHCP. Si son incorrectas o faltan, el error sigue estando en la configuración DHCP. Si son correctas, se comprueban a continuación la resolución interna de nombres y el acceso de red al servidor DNS.

Una interfaz RED tiene un caso especial adicional: si su dirección se cambia por otra situada fuera del rango dinámico existente, SFOS desactiva el servidor DHCP RED asociado. Después deben adaptarse Dynamic IP lease, las asignaciones estáticas y los valores DNS a la subred resultante de la interfaz, o crearse una nueva configuración de servidor. Solo entonces se vuelve a poner en servicio el ámbito y se prueba con un cliente.

Sustituir un servidor DHCP existente

Durante una migración, el nuevo servidor DHCP no debe activarse simplemente junto con el anterior. Los clientes activos conservan su concesión existente; el nuevo servidor desconoce esas asignaciones y podría ofrecer una dirección que todavía está en uso.

Para realizar un cambio controlado, se sigue este procedimiento:

Documentar el rango, las opciones, las asignaciones estáticas y las concesiones activas del servidor actual.
Acortar con antelación el tiempo de concesión en el servidor antiguo y esperar hasta que los clientes activos hayan renovado su concesión con el valor más corto.
Detener el servidor actual y activar inicialmente el nuevo servidor con un rango de transición que no se solape.
Renovar las concesiones de varios clientes distintos y comprobar la puerta de enlace, DNS y la conectividad.
Una vez caducadas las concesiones antiguas, activar el rango definitivo y restablecer el tiempo de concesión normal.

Conflict detection resulta útil durante una migración, pero no sustituye esta planificación. La función comprueba una dirección antes de asignarla, pero no mantiene una base de datos de concesiones compartida con el servidor antiguo.

Para volver atrás, se conserva un registro completo de la configuración anterior. Si el nuevo ámbito distribuye valores incorrectos, se desactiva o elimina únicamente esa nueva configuración de servidor y se vuelve a activar el servidor anterior de forma controlada. En cambio, System services > Services > DHCP server > Stop detiene el servicio DHCP global y, por tanto, todos los ámbitos locales; solo debe utilizarse cuando se pretende exactamente ese efecto general. Después se renuevan las concesiones en varios clientes de prueba.

Los valores especiales, como servidores de arranque PXE, controladores VoIP u opciones de fabricante, deben compararse por separado antes del cambio. No forman parte automáticamente de la distribución normal de dirección, puerta de enlace y DNS.

Automatización: estado de una configuración DHCP con nombre

La documentación de la API XML para SFOS 22 y 23 describe DHCPServerStatus con los campos obligatorios DHCPServerNamedhcpname y Status. DHCPServerNamedhcpname es la grafía literal documentada, no un nombre de campo corregido aquí. El nombre identifica la configuración de servidor DHCP seleccionada, como dhcp-vlan20-clients, no el servicio DHCP global. Un cambio de estado de este ámbito con nombre no debe confundirse con el Stop global descrito arriba.

Para Status, el ejemplo muestra ON/OFF, mientras que la tabla de parámetros indica INTEGER. No se proporciona ninguna correspondencia numérica ni valor predeterminado; ambos campos son obligatorios. Esto no permite deducir una codificación segura ni el comportamiento al omitir campos. Por tanto, no se debe automatizar un cambio de estado XML a partir de este ejemplo. Hasta aclarar el esquema de campos y la codificación del estado para la versión instalada, se sigue utilizando el procedimiento GUI existente en Network > DHCP para la configuración de servidor seleccionada; el servicio global se controla por separado en System services > Services.

Antes de un cambio, registrar el nombre, la interfaz, el rango de direcciones y el estado anterior del ámbito de destino. Después, comprobar esa configuración exacta y que los demás ámbitos no hayan cambiado, y realizar con clientes controlados las comprobaciones de concesión, puerta de enlace, DNS y conectividad descritas arriba. Al desactivar el ámbito, verificar que ya no entregue concesiones nuevas; una concesión de cliente que todavía existe no lo demuestra. Los resultados API documentados 200 (Operation Successful) y 500 (Operation Fail) no son pruebas funcionales; HTTP 200 por sí solo tampoco confirma el destino correcto ni el estado del cliente. Para revertir, restaurar exactamente el estado registrado y repetir las comprobaciones de los clientes.

Modificar los ajustes DHCP globales solo cuando sea necesario

En SFOS 23, Network > DHCP > Advanced server settings contiene estos dos campos de la interfaz:

Allow only one lease per client limita cada cliente a una sola concesión DHCP. Cuando está activado, cada cliente recibe una única dirección IP concedida.
Negative acknowledgement activa respuestas DHCPNAK cuando un cliente solicita una dirección fuera de la subred configurada del servidor o una dirección ya asignada. Conflict detection, en cambio, es la comprobación independiente de una dirección antes de asignarla.

Antes de un cambio en la interfaz, registrar el valor anterior. Después, renovar una concesión de cliente, comprobar IPv4 lease y, si es necesario, una captura de paquetes UDP 67/68. Para revertir el cambio, restaurar exactamente el valor registrado. Siguen siendo aplicables las indicaciones CLI siguientes sobre el efecto global, la identidad del cliente y los riesgos de NAK.

Otros dos interruptores de Device Console afectan al servicio DHCP completo. Antes de realizar un cambio, se consulta la ayuda local específica de los comandos one-lease-per-client y send-dhcp-nak en la versión instalada. Se registra el estado actual de ambos interruptores mediante una consulta de solo lectura admitida en esa versión o una visualización disponible en la interfaz de usuario, y se confirma la sintaxis tanto para el cambio como para la reversión. Aquí no se presupone que una forma concreta de show ni un valor predeterminado sean válidos para todas las versiones. Si no se pueden determinar de forma fiable el estado inicial o el procedimiento de reversión, no se realiza ningún cambio y primero se consulta al soporte técnico.

Cuando está activado, one-lease-per-client limita la asignación de concesiones por cliente. Se debe aclarar localmente cómo identifica al cliente la versión instalada en los casos especiales. La activación se aplica a todas las configuraciones de servidor DHCP de este firewall; por eso, al principio se limita únicamente la prueba a un cliente controlado y después se comprueban la tabla de concesiones, la renovación y los dispositivos con varias interfaces o una dirección MAC cambiante.

Cuando está activado, send-dhcp-nak permite respuestas DHCPNAK. Un DHCPNAK rechaza una dirección que el servidor no acepta y obliga al cliente a volver a la negociación DHCP. Desactivarlo puede prolongar estados de cliente no válidos y no es una solución general para concesiones fallidas.

Solo si la ayuda local confirma esta sintaxis para la versión instalada y se han registrado el estado inicial y el procedimiento de reversión, se modifican los interruptores de la siguiente manera:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Los corchetes son marcadores de posición; solo se ejecuta el valor necesario. Después del cambio, se vuelve a comprobar el valor mediante la misma consulta de solo lectura admitida o visualización de la interfaz de usuario, se renueva una concesión, se revisa IPv4 lease y, si es necesario, se realiza una captura de paquetes en UDP 67/68. Para revertir el cambio, se restauran exactamente los valores registrados antes del cambio con la sintaxis confirmada previamente y se vuelven a comprobar ambos interruptores. system dhcp one-lease-per-client disable y system dhcp send-dhcp-nak enable solo son valores de reversión adecuados si el primer interruptor estaba desactivado o el segundo estaba activado, respectivamente, y la ayuda local confirma esta sintaxis.