Un dhcp server bien configurado evita que tengas que asignar a mano cada IP, máscara, puerta de enlace y DNS en la red de casa o de la oficina. En este artículo explico cómo funciona ese reparto automático, qué datos entrega además de la dirección, por qué a veces parece que falla el WiFi cuando en realidad falla otra cosa y qué ajustes conviene tocar para que la red sea más estable y más segura.
Las claves que conviene tener claras antes de tocar la red
- El servidor DHCP automatiza la asignación de IP y otros parámetros básicos de red.
- En una WiFi, el problema suele estar en DHCP, en la VLAN o en el relay, no en la señal.
- Si ves una IP 169.254.x.x, el dispositivo no ha recibido una concesión válida.
- Las reservas DHCP son la mejor opción para impresoras, NAS, cámaras y puntos de acceso.
- Un servidor DHCP falso puede desviar tráfico si no hay controles como DHCP snooping.
Qué problema resuelve un servidor DHCP
La idea es simple: evitar la configuración manual repetida en cada dispositivo que entra en la red. Cuando conectas móviles, portátiles, televisores, consolas, impresoras o sensores IoT, el servidor DHCP centraliza el reparto de direcciones y reduce errores de copia y pega. Sin eso, cada equipo tendría que llevar su IP, su máscara, su puerta de enlace y sus DNS escritos a mano, y cualquier duplicado acaba en conflicto.
En una red doméstica típica con una subred /24, dispones de 254 direcciones utilizables. Parece mucho, pero entre invitados, dispositivos temporales y equipos que cambian de red, ese margen se consume antes de lo que parece. Yo suelo pensar en DHCP como una pieza de higiene operativa: no se nota cuando funciona, pero se echa mucho de menos cuando desaparece.
Además, el mismo mecanismo sirve tanto por cable como por WiFi. El medio cambia, pero la lógica es la misma: el cliente entra en la red y pide configuración automática. Y precisamente porque no solo reparte una IP, conviene mirar el proceso con un poco más de detalle.
Cómo reparte direcciones sin que choquen
El intercambio clásico se conoce como DORA, por sus cuatro pasos: descubrimiento, oferta, solicitud y confirmación. En IPv4, el tráfico DHCP viaja por UDP 67 y 68; por eso una VLAN mal montada, un filtrado demasiado agresivo o la ausencia de relay pueden romperlo aunque el SSID esté funcionando.
Lee también: ¿WiFi hackeado? Descubre cómo saberlo y proteger tu red
La secuencia DORA en cuatro pasos
- Descubrimiento: el cliente lanza un mensaje para localizar servidores DHCP disponibles.
- Oferta: el servidor responde con una IP posible y con los parámetros básicos de red.
- Solicitud: el cliente elige una oferta y pide esa dirección de forma explícita.
- Confirmación: el servidor valida la petición y entrega la concesión, es decir, el alquiler temporal de esa IP.
En redes segmentadas, hay un matiz importante: los broadcasts no cruzan subredes por sí solos. Si el servidor está en otra VLAN, hace falta un relay DHCP para reenviar las peticiones. Cuando eso falta, el cliente “ve” la WiFi pero no consigue dirección, y el fallo parece más grande de lo que es. En IPv6 la historia cambia de forma parcial: DHCPv6 usa otros puertos y puede convivir con SLAAC, pero la lógica de automatizar la configuración sigue siendo la misma.
Con ese flujo claro, ya se entiende mejor por qué el DHCP no solo asigna una IP, sino que entrega la receta completa para que el equipo salga a la red.
Qué más entrega además de la IP
La IP es solo la primera pieza. En la práctica, el servidor también reparte otros datos que determinan si el equipo navega, resuelve nombres o se queda atascado en una red local sin salida. Si uno de esos parámetros llega mal, el usuario suele culpar al WiFi aunque el problema esté en la configuración de red.
| Dato | Para qué sirve | Qué pasa si falta |
|---|---|---|
| Máscara de subred | Define qué direcciones pertenecen a la red local | El equipo no distingue bien entre tráfico local y tráfico que debe enviar al router |
| Puerta de enlace | Indica por dónde sale el tráfico hacia Internet u otras redes | Hay IP válida, pero no hay salida real |
| DNS | Convierte nombres de dominio en direcciones IP | La navegación parece caída aunque la conectividad exista |
| Tiempo de concesión | Marca cuánto dura la IP prestada | La red renueva demasiado a menudo o retiene direcciones más de la cuenta |
| Opciones extra | NTP, sufijo de búsqueda y otros parámetros específicos | Algunos servicios quedan mal afinados o fallan de forma parcial |
Esto también explica por qué una IP manual no siempre es la mejor respuesta. Si el problema real es que el DNS está mal entregado o que la puerta de enlace no coincide con la VLAN correcta, fijar una IP a ciegas no arregla nada. En cambio, una reserva bien hecha conserva la automatización y evita que cada equipo tenga que configurarse por separado.
La siguiente pregunta lógica es cuándo conviene dejar que DHCP actúe solo, cuándo reservar y cuándo merece la pena una IP fija de verdad.
Cuándo conviene DHCP, reserva o IP fija
Yo suelo separar estos tres escenarios, porque no resuelven lo mismo. DHCP automático es ideal para dispositivos móviles y para todo lo que cambia de red con frecuencia. La reserva DHCP conserva la asignación automática, pero fija siempre la misma IP para un equipo concreto. La IP fija solo tiene sentido cuando quieres controlar manualmente un servicio o una infraestructura muy concreta.
| Opción | Cuándo encaja mejor | Ventaja principal | Riesgo o límite |
|---|---|---|---|
| DHCP automático | Móviles, portátiles, tablets, invitados | No requiere mantenimiento por equipo | La IP puede cambiar |
| Reserva DHCP | Impresoras, NAS, cámaras, puntos de acceso, Home Assistant | IP estable con control central | Depende de la MAC y de que la reserva esté bien documentada |
| IP fija | Servicios muy específicos o equipos aislados | Control total desde el propio dispositivo | Más fácil provocar conflictos si se mete dentro del rango DHCP |
En la práctica, muchas peticiones de IP fija se resuelven mejor con una reserva. Es menos frágil, más cómoda de auditar y evita que cada cambio de router o de subred obligue a revisar media red. Solo me inclino por IP manual cuando el dispositivo lo exige o cuando hay una razón muy concreta para salir del esquema centralizado.
Y, una vez elegido el modelo, toca mirar lo que más problemas da en redes WiFi: los fallos que parecen de cobertura pero en realidad son fallos de asignación.
Dónde suele fallar en redes WiFi
Hay una confusión muy habitual: si el móvil se conecta al SSID pero no navega, mucha gente asume que el problema es la señal. No siempre es así. Yo reviso primero si el cliente ha recibido una IP válida, si la puerta de enlace y el DNS son correctos y si existe un relay cuando el servidor está en otra VLAN. La señal puede estar perfecta y la red seguir rota a nivel de configuración.
| Síntoma | Causa probable | Qué reviso primero |
|---|---|---|
| IP 169.254.x.x | No llegó respuesta DHCP | Servidor apagado, pool vacío, relay ausente o VLAN incorrecta |
| Conecta al SSID pero no hay Internet | Gateway o DNS mal entregados | Opciones DHCP y estado del router |
| Funciona por cable, no por WiFi | Segmentación o aislamiento mal planteados | SSID, VLAN, AP y reglas de red |
| Solo fallan algunos equipos | Rango pequeño, reservas conflictivas o servidor falso | Uso del pool y duplicados |
La IP 169.254.x.x merece una mención aparte: es una autoconfiguración de emergencia, no una dirección normal de la LAN. El equipo la usa cuando no ha conseguido una concesión válida. Si aparece, casi nunca el problema es “la contraseña del WiFi”; el problema suele estar en el camino entre el cliente y el servidor DHCP.
Hay otro error doméstico muy frecuente: dejar dos servidores DHCP activos en el mismo segmento, por ejemplo un router principal y otro viejo en modo router en vez de punto de acceso. Eso genera respuestas inconsistentes y hace que unos equipos reciban una puerta de enlace correcta y otros no. En redes pequeñas, ese detalle causa más incidencias de las que parece.
Por eso conviene mirar también la capa de seguridad. El DHCP no solo puede fallar por accidente; también puede usarse de forma maliciosa.
Cómo endurecerlo frente a abusos y errores
Un servidor DHCP falso no necesita romper WPA3 para causar daño. Si un cliente acepta su oferta antes que la del servidor legítimo, puede acabar con un gateway o un DNS controlado por un tercero. Eso basta para desviar tráfico, filtrar consultas o dejar servicios inaccesibles. En una red WiFi bien defendida, el DHCP también se protege, no solo el acceso inalámbrico.
- Activa DHCP snooping en switches gestionables para confiar solo en los puertos realmente autorizados.
- Separa invitados e IoT en SSIDs o VLAN distintas para reducir el impacto de un equipo comprometido.
- Desactiva DHCP en routers antiguos que uses como punto de acceso, para no crear servidores duplicados.
- Ajusta la concesión con criterio: más corta en invitados, más estable en la red principal.
- Documenta reservas y rangos para no meter IPs manuales dentro del pool dinámico.
- Protege la administración del router y mantén el firmware actualizado, porque el servidor DHCP suele vivir ahí.
En equipos de red gestionables, DHCP snooping funciona como una especie de filtro entre fuentes confiables y no confiables. No es magia, pero sí una capa muy útil para bloquear respuestas que no deberían existir. Si además separas bien las subredes y reduces el número de dispositivos que comparten el mismo dominio de broadcast, el margen para errores y ataques baja bastante.
Con esa base, el comportamiento deja de depender de improvisaciones y se vuelve predecible. Lo último es condensarlo en una configuración práctica que no complique la vida más de la cuenta.
La configuración que yo dejaría en una red pequeña bien resuelta
Si montara una red doméstica o de pequeño despacho desde cero, dejaría DHCP activo para casi todo, usaría reservas para los equipos fijos y reservaría la IP manual solo para casos muy concretos. En una LAN típica, un rango dinámico como 192.168.1.100 a 192.168.1.199 suele dejar espacio suficiente para crecer, mientras que las direcciones reservadas pueden quedar fuera de ese bloque para no pisarse.
- DHCP para móviles, portátiles, televisores y equipos de paso.
- Reserva DHCP para impresoras, NAS, cámaras, puntos de acceso y domótica crítica.
- Rangos separados para red principal, invitados e IoT.
- Lease más corto en invitados y más estable en la LAN principal.
- Sin duplicados: ningún equipo con IP fija debe vivir dentro del pool dinámico.
Ese esquema no solo ordena la red; también facilita el diagnóstico cuando algo falla. Si el WiFi da conexión pero no hay navegación, ya no tienes que adivinar si el problema está en la radio, en la puerta de enlace o en el reparto de IPs. Y si aparece un comportamiento raro, el servidor DHCP deja pistas claras para revisar qué dirección recibió cada equipo y desde dónde.
En una red pequeña, esa es la diferencia entre una configuración que funciona por casualidad y otra que se puede mantener sin pelearse con ella cada semana.
