Algo robusto y único, generado con gestor de contraseñas. Por terminal: passwd.

Esto solo lo recomiendo si sabes que estas haciendo. Si decides que el tema de las keys no son lo tuyo puede estar bien cambiar el puerto de ssh del 22 a otro para dificultar el acceso.

Paso 1 — Genero el par de claves en mi ordenador (si no lo tengo ya):

Paso 2 — Pego la clave pública en System → Administration → SSH-Keys. O por terminal:

Paso 3 — VERIFICO que entra con la clave antes de tocar nada más. Dejo la sesión de LuCI abierta, abro otra terminal, y pruebo:

Si entra sin pedirme contraseña, sigo. Si falla, no toco nada más hasta resolverlo, este es el paso donde la gente se queda fuera de su propio router.

Paso 4 — Ahora sí, cierro el acceso por contraseña:

Por LuCI es System → Administration → SSH Access: desmarcar Password authentication y Allow root logins with password, y poner Interface en lan.

Trampa que me pilló: en versiones recientes de LuCI apareció un checkbox nuevo, Bind to Interface, separado del desplegable "Interface". Puedes tener Interface: lan seleccionado y aun así dropbear seguir escuchando en todas las interfaces si ese checkbox no está marcado. Márcalo. Para verificarlo de verdad:

# ¿En qué IPs está escuchando el 22?
netstat -tlnp | grep :22
# Debería mostrar solo 192.168.0.1:22, NO 0.0.0.0:22

System → Administration → HTTP(S) Access → marcar Redirect to HTTPS. O:

El certificado autofirmado dará un aviso en el navegador la primera vez , es normal para uso doméstico, solo hay que aceptar la excepción una vez por dispositivo. También puedes usar Nginx Proxy Manager para dar una dirección con certificado, es lo que utilizo yo.

Con esto, el objetivo de fondo (que ni SSH ni LuCI sean alcanzables desde wan) queda apalabrado aquí, aunque la confirmación definitiva llega en la Fase 6, cuando monte el firewall.

Configuro el protocolo según lo que pida mi ISP. En mi caso PPPoE sobre una VLAN etiquetada (algunos operadores de fibra en España piden la VLAN 20 o similar):

Dejo el IPv6 en modo automático (auto), para que si el ISP delega un prefijo por DHCPv6-PD, el router lo reciba y lo tenga disponible.

IP estática, protocolo static:

Aquí la clave es que no es una interfaz física nueva, sino una red lógica propia a la que luego ataré un SSID de WiFi dedicado (Fase 4). Lo importante es que quede como una interfaz static independiente de la LAN, con su propio rango de IPs, para que el firewall pueda tratarla como una zona separada:

Esta es la parte que quiero documentar bien para mi yo del futuro, porque tiene su matiz:

En la interfaz LAN, voy a DHCP Server → IPv6 Settings y pongo RA-Service, DHCPv6-Service y NDP-Proxy en disabled. Esto hace que ningún dispositivo de mi LAN reciba una dirección IPv6 pública — se quedan solo con IPv4 (y, como mucho, una dirección fe80:: link-local que no sale de la red y no cuenta).

No toco nada en la WAN : dejo que wan6 (el cliente DHCPv6) siga pidiendo y manteniendo su prefijo delegado con normalidad.

Por terminal:

¿Por qué esta combinación y no simplemente apagar IPv6 del todo? Porque así el router mantiene la conectividad IPv6 "viva" de cara a mi ISP, sin exponer nada hacia mis dispositivos internos. Si en el futuro quiero activar IPv6 en la LAN, solo tengo que volver a esta pantalla y reactivar esos tres servicios. Pero aun así, con el tamaño de una red domestica, creo que IPv4 simplifica la gestión.

Para verificar que ha funcionado, desde un dispositivo de la LAN:

Solo debería quedar, como mucho, alguna fe80::... (link-local, normal, no cuenta). Ninguna dirección global que empiece por 2xxx:.

Aviso importante que aprendí a las malas: hay una diferencia entre "el router tiene una IPv6 en su interfaz LAN" y "el router reparte IPv6 a los clientes". Lo primero es normal y no importa; lo segundo es lo que estamos apagando. Ver una IPv6 en br-lan en la pantalla de interfaces no significa que tus dispositivos la tengan.

Y otro: no desactives las reglas de firewall de ICMPv6 (Allow-ICMPv6-Input, Allow-ICMPv6-Forward) si vas a dejar IPv6 activo en algún sitio. IPv6 depende de ICMPv6 para funcionar (Neighbor Discovery, Path MTU Discovery). Desactivarlas mientras IPv6 sigue vivo da síntomas raros e intermitentes, webs que a veces cargan y a veces no, en vez de un apagado limpio.

Si auto-hospedo servicios, creo los registros en DNS → DNS Records → Hostnames para que, estando en casa, el dominio público resuelva directamente a la IP interna en vez de salir a internet y volver a entrar:

Para verificar que todo el bloque DNS funciona:

# ¿Resuelve mi dominio interno a la IP privada?
nslookup nextcloud.dominio.duckdns.org 192.168.0.1

# ¿Y qué tiene publicado el mundo exterior? (saltándome mi propio resolver)
nslookup dominio.duckdns.org 1.1.1.1

Esa segunda consulta, forzando un DNS externo, es la única forma fiable de saber qué hay publicado de verdad. Si preguntas a tu propio router, te contestará tu anulación local y te engañarás a ti mismo. Este detalle me costó un buen rato de depuración con el DDNS (ver Fase 8).

1. Comprobar dos veces el campo "Network" de cada SSID.

En General Setup → Network, un SSID puede tener varias redes marcadas a la vez. Si tu SSID principal tiene marcadas lan y iot, estás puenteando ambas redes a nivel de enlace, y toda la segmentación de firewall que montes después no sirve absolutamente de nada, el tráfico se mezcla antes de llegar al firewall. Verificación rápida:

2. "Isolate Clients" en el SSID de IoT (Advanced Settings → Isolate Clients).

Esto impide que dos dispositivos conectados al mismo WiFi se hablen directamente a nivel de enlace, sin pasar por el router. Es imprescindible como complemento a las reglas de firewall: el Intra zone forward: reject que pondremos en la Fase 6 actúa una capa por encima y no ve ese tráfico si esto no está activado. Yo lo activo también en el SSID principal.

El filtrado por MAC lo dejo como algo opcional y de bajo valor real, se salta con facilidad falsificando la dirección, así que no me la juego solo a esto. Y ojo: dejar macfilter='deny' con la lista vacía no filtra nada, solo da falsa sensación de seguridad.

uci set network.algineerWG=interface
uci set network.algineerWG.proto='wireguard'
uci set network.algineerWG.private_key='<clave privada del router>'
uci set network.algineerWG.listen_port='51820'
uci add_list network.algineerWG.addresses='10.10.10.1/24'
# Empujo mi DNS local a los clientes VPN, así también les aplica el filtrado
uci add_list network.algineerWG.dns='192.168.0.1'
uci commit network

El dns='192.168.0.1' es un detalle que agradezco: hace que mis dispositivos, cuando están conectados por VPN desde fuera, sigan usando mi resolver local y por tanto sigan teniendo bloqueo de anuncios y resolución de mis dominios internos.

En cada dispositivo cliente genero su propio par de claves y le añado su entrada aquí. Nada de compartir la misma clave entre varios sitios — con un peer por dispositivo puedo revocar el acceso de uno solo sin afectar al resto.

Ejemplo de asignación de IPs del túnel, para no perderme:

Un peer puede no ser un dispositivo, sino una red entera. Si algún día conectas otra vivienda (enlace site-to-site), su entrada tendrá un allowed_ips con dos valores: la IP del túnel y la subred remota completa (por ejemplo 10.10.10.8/32 y 192.168.8.0/24), más una ruta estática apuntando a ella. Eso significa que todos los dispositivos de esa red remota heredan el mismo nivel de acceso que cualquier otro peer de la VPN mucho más de lo que probablemente quieras. Lo trato en la Fase 7.

Si mi IP pública es dinámica, los clientes necesitan un dominio en vez de una IP. Lo monto en la Fase 8 con ddns-scripts, pero lo apunto aquí porque conceptualmente pertenece a la VPN: el endpoint_host de todos mis clientes apunta a ese dominio, así que si el DDNS falla y la IP cambia, pierdo el acceso remoto de golpe. No es un accesorio, es parte crítica del acceso.

Un peer con latest handshake reciente = conectado y funcionando. Si nunca ha hecho handshake, el problema suele ser: puerto no abierto en el firewall (Fase 7), DDNS mal, o claves cruzadas.

En Network → Firewall → General Settings, dos casillas de coste cero y sin efectos secundarios:

uci set firewall.@defaults[0].synflood_protect='1'
uci set firewall.@defaults[0].drop_invalid='1'
uci commit firewall
/etc/init.d/firewall restart

SYN-flood protection: mitiga ataques de inundación de conexiones TCP a medio abrir.

Drop invalid packets: descarta paquetes que no encajan en ningún estado de conexión conocido, a veces usados para evadir firewalls o escanear de forma sigilosa.

Cuidado con las "zonas decorativas". En su día creé una zona llamada bloquearIOTaLAN para "documentar" la intención de bloquear ese tráfico. El problema: no tenía ninguna red asignada (covered networks: unspecified), así que era completamente inerte, no bloqueaba nada, solo daba una falsa sensación de seguridad. Lo que protegía de verdad era, simplemente, que lan no estuviera en la lista de destinos de iot. Si una zona no tiene redes, no hace nada: mejor borrarla que confiar en ella.

OpenWrt trae de fábrica: Allow-DHCP-Renew, Allow-Ping, Allow-IGMP, Allow-DHCPv6, Allow-MLD, Allow-ICMPv6-Input, Allow-ICMPv6-Forward. Ninguna compromete la seguridad.

Allow-Ping: puedo desactivarlo si prefiero que mi router no responda a pings desde internet. Es más "perfil bajo" que seguridad real: un ping no expone ningún servicio ni permite ejecutar nada, solo confirma "hay algo vivo aquí". Cuestión de gustos.

Las de ICMPv6: si dejo IPv6 activo en la WAN (mi caso), las dejo tal cual. Ver el aviso de la Fase 2.

Aquí es donde encontré basura real: tenía activas Allow-IPSec-ESP y Allow-ISAKMP (reenvío WAN → LAN de protocolo ESP y UDP/500) de una configuración IPsec antigua que ya no usaba, porque me había pasado a WireGuard. Puertos abiertos hacia mi LAN sin ningún propósito = superficie de ataque gratis.

Regla general: cualquier regla de un protocolo VPN que no uses, fuera.

Es la única puerta que abro desde internet:

uci add firewall rule
uci set firewall.@rule[-1].name='Allow-WireGuard'
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].dest_port='51820'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

Solo UDP (WireGuard no usa TCP).

Un puerto exacto, nunca un rango.

Sin restringir la IP de origen — mis dispositivos conectan desde cualquier red (datos móviles, WiFi ajeno...).

💡 El puerto por defecto 51820 es el primero que prueban los escáneres automáticos. No es un agujero real, WireGuard es "sordo y mudo" ante quien no tenga la clave correcta, no responde nada a paquetes no autenticados pero cambiarlo a un puerto alto arbitrario reduce el ruido en los logs. Cosmética de seguridad, opcional.

Como puse Input: reject en la zona iot, los dispositivos ya no pueden ni pedir IP. Necesito dos excepciones quirúrgicas:

# DHCP — SIN restricción de IP de destino
uci add firewall rule
uci set firewall.@rule[-1].name='Permitir DHCP a IoT'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='67-68'
uci set firewall.@rule[-1].target='ACCEPT'

# DNS — aquí SÍ puedo fijar la IP de destino
uci add firewall rule
uci set firewall.@rule[-1].name='Permitir DNS a IoT'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].proto='tcp udp'
uci set firewall.@rule[-1].dest_ip='192.168.10.1'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

La trampa del DHCP. En la regla de DNS puedo fijar dest_ip porque las consultas DNS siempre van dirigidas (unicast) a una IP que el cliente ya conoce. Pero en DHCP no debo fijarla: cuando un dispositivo nuevo se conecta por primera vez, todavía no tiene IP y no sabe cuál es el servidor, así que el DHCPDISCOVER inicial va por broadcast (255.255.255.255). Si fijas la IP de destino, los dispositivos que ya tenían lease seguirán renovando bien, pero ningún dispositivo nuevo conseguirá IP jamás, un fallo que tarda semanas en aparecer y es un infierno de diagnosticar.

El DHCP-Option 6 de la Fase 3 es una sugerencia que cualquier dispositivo (o malware) puede ignorar usando 8.8.8.8 directamente. Esta regla lo convierte en obligación:

Nota importante: esta regla es de tipo forward (afecta al tráfico reenviado de mis clientes hacia fuera), no de tipo output. El propio dnsmasq del router sigue pudiendo consultar a sus servidores upstream con total normalidad.

Uso REJECT y no DROP a propósito: con reject, la app falla rápido y sé enseguida qué se ha roto, en vez de quedarme esperando un timeout eterno.

¿Aplicarlo también a la LAN? Es un trade-off consciente. Si mis dispositivos tienen 1.1.1.1 como DNS secundario para que internet siga funcionando si mi resolver local se cae, esta regla se lo rompería. La alternativa elegante es mover ese "plan B" al propio router (configurar 1.1.1.1 como upstream de dnsmasq, que ya está en la Fase 3) y entonces sí bloquear el 53 saliente también en LAN: mantienes la resiliencia y ganas que el filtrado de anuncios aplique siempre.

Límite conocido: esto no detiene DNS-over-HTTPS (DoH), que viaja camuflado por el puerto 443 como tráfico web normal. Bloquear DoH es harina de otro costal (listas de IPs de resolvers conocidos, y con riesgo de romper cosas). Lo dejo apuntado como tarea futura.

Cuando necesito que un dispositivo de la LAN llegue a algo concreto de la red IoT, no abro la zona entera. Ejemplo real: acceder al panel web de un cacharro que vive en la red IoT:

Host concreto + puertos concretos. Este es el patrón a repetir para cualquier excepción entre segmentos.

Si algún peer es en realidad un enlace a otra red completa (segunda vivienda, casa de un familiar), no lo trates como "un dispositivo más". Tu seguridad pasa a depender de lo bien protegida que esté esa otra red, sobre la que probablemente no tengas control diario.

Ejemplo de acotación puntual (bloquear una cámara concreta de la red remota, permitiendo el resto):

Al ser una coincidencia más específica que la política general de la zona, tiene prioridad sobre ella.

Guarda ese archivo. Es lo que te permitirá comparar tras una actualización de firmware y detectar qué se quedó fuera.

Puedes preguntar a tu LLM de confianza que te analice los paquetes y te sugiera si sobra alguno con el objetivo que buscas.

Repásalo entero, línea a línea si hace falta. En builds de terceros (como la que instalé) puedes encontrar cosas que nunca pediste. En la mía apareció, entre otras:

Un kit completo de evasión de censura (zapret, podkop, ruantiblock, amneziawg) herramientas legítimas para saltarse el bloqueo de internet en otros países, pero completamente inútiles y superfluas en mi contexto.

Un logger de URLs (urllogger) que registraba tráfico de mi red sin que yo lo hubiera decidido.

Protocolos VPN antiguos e inseguros "por si acaso": pptp, l2tp, openvpn que no usaba.

Túneles que no necesito: 6in4, 6rd, 6to4, gre, batman-adv, relayd.

Un puñado de paquetes de idioma de un idioma que no hablo (luci-i18n-*-ru).

Terminales web redundantes (ttyd) teniendo ya SSH bien configurado.

Tres lecciones que aprendí borrando:

Un paquete "motor" y su luci-app-* suelen ser dos paquetes separados. Si solo borras la app de LuCI, el demonio sigue corriendo. Bórralos juntos en el mismo comando: apk del relayd luci-proto-relay.

Cuidado con las regex. Usé grep -oE 'luci-i18n-[a-zA-Z0-9]+-ru' para borrar paquetes de idioma en bloque, y falló de dos formas: se dejó fuera los que tenían guion interno (luci-i18n-package-manager-ru), y un grep -- '-ru' a secas también capturaba luci-lua-**ru**ntime — que es el runtime de Lua del que depende toda la interfaz web. Lista primero, revisa, borra después.

Algunos paquetes "raros" tienen una razón de ser. kmod-mtd-rw y facinstall parecían basura, pero resultaron ser las herramientas que permiten volver al firmware de fábrica desde OpenWrt en routers Xiaomi. No son un riesgo (no escuchan en ningún puerto, no corren de fondo) y son tu botón de pánico. Investiga antes de borrar.