¿Por qué el DNS propio del router evita el túnel VPN?

Las consultas de los clientes siguen el túnel, mientras que las consultas propias del router salen por la WAN, y la regla de cortafuegos que gobierna una no tiene ningún efecto sobre la otra. La razón no es un fallo: una petición reenviada y una petición que genera el router son dos flujos separados, y cada uno se compara con una parte distinta de la configuración. Capturar solo la mitad del cliente produce una respuesta segura sobre un camino que la segunda mitad nunca usa. La reparación consiste en apuntar deliberadamente el resolutor del router y después probar los dos caminos por separado.

A qué flujo pertenece realmente la captura de paquetes

Una consulta implica dos intercambios. Un cliente de la LAN envía una consulta al resolutor del router, y esta llega como tráfico reenviado en la interfaz LAN, así que una ruta de política o una regla NAT escrita para paquetes reenviados puede hacerla coincidir. Después el router responde desde la caché o, si no hay entrada, abre su propia consulta a un servidor ascendente.

Esa segunda consulta tiene al router como origen y como destino propio, y la plataforma elige su camino en un bloque de configuración distinto. Ambos intercambios llevan el mismo nombre, y ninguno es una copia del otro. Por eso una captura tomada en el lado de la LAN demuestra adónde fue el paquete del cliente y no dice nada sobre el paquete saliente.

La comprobación práctica es observar ambos lados a la vez. En el router, lista el socket del resolutor, consúltalo localmente y captura la interfaz WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Si la lista de sockets muestra un oyente ligado a la dirección de loopback o de la LAN, el router responde localmente en lugar de reenviar a otro host. La captura muestra entonces si la consulta ascendente resultante sale por la interfaz del túnel o por la WAN, que es la respuesta que la regla de ruta de política nunca habría dado.

Por qué la ruta de política nunca ve la segunda consulta

Las reglas de cortafuegos se escriben para una interfaz, un origen, un destino y un puerto, y se evalúan para los paquetes que pasan por el equipo. Una consulta que origina el router no pasa por nada, porque un proceso local la entrega directamente a la tabla de enrutamiento. Enrutamiento por política y NAT por tanto, solo se aplican al camino reenviado, y por eso un conjunto de reglas puede parecer completo y aun así dejar el DNS del router fuera del túnel.

La distinción sobrevive a cada reescritura del firmware porque se deriva del camino del paquete y no de una función. Todo lo que el equipo genera para sí mismo, ya sean consultas del resolutor, sincronización de la hora, comprobaciones de actualizaciones o acceso a espejos de paquetes, es de origen local y cae en el mismo punto ciego. Es también por eso que una prueba hecha desde un portátil no demuestra nada sobre el router.

Dónde decide el resolutor de pfSense su propio camino ascendente

pfSense hace visible la separación. El tráfico de los clientes puede enrutarse por política a través de una puerta de enlace VPN mientras el tráfico propio del cortafuegos sigue el ajuste de salida del resolutor en lugar de las reglas de la LAN. En la interfaz web ese ajuste se encuentra en Services > DNS Resolver > Outgoing Network Interfaces, y su valor es la lista de interfaces que el resolutor puede usar para consultas ascendentes.

Nombrar allí la interfaz del túnel, y solo esa interfaz, es lo que hace que las consultas propias del router sigan el túnel. Si se deja por defecto, el resolutor elige una salida de la tabla de enrutamiento, que en un host con doble WAN o VPN suele ser la WAN.

Otros firmwares exponen la misma decisión con otra etiqueta: una lista de servidores ascendentes ligada a una dirección de origen, un modo de solo reenvío o una política de rutas documentada. El ajuste que hay que buscar es siempre el que elige una salida o un origen para las consultas generadas localmente. La referencia de configuración del resolutor documenta esa opción para pfSense y merece leerse antes del cambio.

Elija el comportamiento ante fallos antes que el ajuste

Cuando el túnel cae, dos comportamientos son defendibles: detener las consultas ascendentes para que nada se escape, o recurrir a un resolutor aprobado por un camino conocido. Ambos son políticas, y ninguno es lo que se obtiene por defecto. Decida cuál necesita la red antes de tocar la lista de interfaces.

El cierre ante fallos es más fácil de defender, pero convierte una caída del túnel en una caída de resolución de nombres para cada dispositivo detrás del router. La alternativa mantiene la oficina utilizable, a costa de un intercambio ascendente fuera del túnel que debe ser aceptable a propósito y no por accidente. Escriba la elección, porque la próxima persona que vea una dirección de resolutor fuera de la VPN lo leerá como una fuga a menos que una nota diga lo contrario. Esa nota es lo que separa una alternativa documentada de un hallazgo sin explicación en la revisión del próximo trimestre.

Dos casos complican la decisión. Los nombres privados pueden necesitar un resolutor interno que el túnel pueda alcanzar, y un navegador o una aplicación con su propio DNS cifrado puede evitar el router por completo, así que el resolutor que configuró no es siempre el que usa una aplicación concreta.

Pruebe ambos caminos y mantenga los resultados separados

Una prueba de DNS en el navegador responde a una pregunta estrecha: qué resolutores usó ese navegador, en las condiciones de esa prueba. No inventaría los dispositivos de la red ni puede ver una consulta que el router generó para sí mismo. Trate su salida como un dato y no como una auditoría.

Desde un cliente de la LAN, pida al router un nombre público y luego uno privado que solo debería responder su zona interna. Un fallo solo en la segunda consulta apunta al reenvío de nombres y no al túnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Luego baje el túnel y repita ambas consultas. Las respuestas rechazadas significan que el resolutor se cierra ante fallos; una respuesta correcta apunta a un resolutor alternativo y al camino que usó. Compare eso con la nota que escribió y con una captura en la interfaz WAN tomada en el mismo minuto.

Mantenga las observaciones separadas en el registro: el intercambio del cliente con el router, el intercambio del router con el ascendente y la configuración que decidió el segundo. Un cambio de enrutamiento posterior ejercitará ese segundo intercambio sin aviso. Una respuesta que llega de un lugar distinto del punto final de la VPN no es una fuga por sí misma; se convierte en fuga solo cuando la configuración eligió ese camino por accidente.