Problema

En entornos donde se conecta una red on‑premise (por ejemplo, un UniFi UDM Pro) a una VPC de AWS mediante un túnel Site‑to‑Site (S2S), es frecuente que el tráfico IP funcione pero la resolución de nombres internos falle. El síntoma típico es que las consultas DNS llegan al endpoint de Route 53 Inbound Resolver (IP 10.x.x.x) y devuelven NXDOMAIN o respuestas vacías, mientras que otras aplicaciones que usan TCP/53 pueden abrir la conexión sin timeout. El problema no se limita a UniFi; cualquier firewall/router que reenvíe consultas a un resolver privado de AWS puede presentar el mismo comportamiento si la cadena de encaminamiento o los atributos del resolver no están alineados.

Causa

Los fallos de DNS en este tipo de arquitectura suelen deberse a una combinación de:

  1. Reglas de reenvío (forwarding) mal configuradas – El dispositivo on‑premise envía la consulta al resolver correcto pero con una IP de origen que no coincide con la permitida en el security group del Inbound Resolver.
  2. Security groups / NACLs demasiado restrictivos – Aunque el puerto 53 esté abierto, la regla puede requerir una dirección IP específica (por ejemplo, la IP del túnel) y descartar el tráfico que proviene de la subred interna del UDM.
  3. Rutas faltantes o asimétricas – La VPC necesita una ruta hacia la subred del cliente (propagada por el VGW) y, a la inversa, el UDM debe tener una ruta estática o una política de “split‑tunnel” que envíe todo el tráfico 10.0.0.0/16 al túnel.
  4. Configuración del resolver de VPC – En la tabla de resolvers de la VPC, si solo está la regla “default” (Internet) y no se ha añadido una regla que apunte al Inbound Resolver para la zona privada, el resolver no sabe que debe buscar en la zona alojada.
  5. Problemas de MTU/MSS – En algunos casos, fragmentación de paquetes UDP de 512 bytes (tamaño típico de DNS) provoca que la respuesta nunca llegue, aunque la petición sí.
  6. Cliente DNS local – El cliente (Windows, Linux, macOS) puede estar usando un DNS caché que devuelve NXDOMAIN antes de que la consulta alcance el resolver remoto.

Solución

1. Verificar y alinear reglas de reenvío en el firewall/router

  • En UniFi, crea una regla de DNS Forwarding que apunte exclusivamente al Inbound Resolver (p.ej., 10.0.152.71) y que preserve la IP de origen del cliente.
  • Desactiva cualquier NAT de salida para tráfico DNS; la IP de origen debe ser la del host interno, no la del UDM.

2. Ajustar security groups y NACLs del Inbound Resolver

  • En el security group asociado al Inbound Resolver, permite UDP y TCP 53 desde todas las subredes que participan en la VPN (p.ej., 10.0.0.0/16 y la subred on‑premise, como 192.168.1.0/24).
  • En la NACL de la subred del resolver, verifica que las reglas de entrada y salida permitan ambos protocolos y rangos de puertos.

3. Confirmar rutas en ambas direcciones

  • En la tabla de rutas de la VPC, añade (o verifica) una ruta 0.0.0.0/0 hacia el Internet y una ruta 192.168.0.0/16 (o la subred on‑premise) con target = vgw‑xxxx.
  • En el UDM, añade una ruta estática 10.0.0.0/16 → túnel VPN. Si usas “policy‑based routing”, asegúrate de que la política incluya el puerto 53.

4. Configurar reglas de resolver en la VPC

  • En la consola de Route 53 Resolver, crea una Resolver Rule del tipo Forward que asocie el dominio interno (p.ej., wfdcommand.com) al Inbound Resolver endpoint.
  • Asocia la regla a la VPC donde está la zona privada. Esto obliga a que cualquier consulta a *.wfdcommand.com sea enviada al endpoint interno y no al resolver público.

5. Probar sin caché y con trazado de paquetes

  • Limpia la caché DNS del cliente (ipconfig /flushdns en Windows, systemd-resolve --flush-caches en Linux).
  • Usa dig @10.0.152.71 <nombre>.wfdcommand.com +tcp +trace para observar el camino de la consulta.
  • Captura paquetes con tcpdump o Wireshark en el UDM (si es posible) para confirmar que la respuesta regresa con la IP de origen esperada.

6. Ajustar MTU si es necesario

  • Reduce la MTU del túnel a 1400 bytes y verifica que las consultas UDP de 512 bytes no se fragmenten.
  • En UniFi, la opción “MTU” suele estar bajo VPN Settings → Advanced.

Cuándo aplicar esta solución

  • Síntomas: VPN estable, ping y tráfico TCP funcionan, pero dig o nslookup devuelven NXDOMAIN o tiempo de espera.
  • Entorno: cualquier sitio‑to‑site entre un firewall/router (UniFi, Palo Alto, Cisco ASA, etc.) y una VPC de AWS que use Route 53 Inbound Resolver y zonas privadas.
  • No aplicar: si la resolución falla porque la zona privada no está asociada a la VPC, o si el problema es exclusivamente local (por ejemplo, DNS interno del cliente sin acceso a internet). En esos casos, la solución se centra en la configuración de la zona o del cliente, no en la VPN.

Código

# Prueba básica de DNS contra el Inbound Resolver
dig @10.0.152.71 srv1.wfdcommand.com +tcp +short

# Limpia caché DNS en Linux (systemd-resolved)
systemd-resolve --flush-caches

# Captura tráfico DNS en la interfaz del túnel (ejemplo en Linux)
tcpdump -i eth0 udp port 53 -vv

Verificación

  1. Conexión al endpoint

    nc -vz 10.0.152.71 53

    Debería mostrar Connection to 10.0.152.71 53 port [tcp/udp] succeeded.

  2. Respuesta correcta
    Ejecuta dig como en el bloque de código y verifica que la sección ANSWER SECTION contenga el registro esperado (A, CNAME, etc.).

  3. Flujo de paquetes
    Con tcpdump observa que la respuesta DNS tiene como IP de origen 10.0.152.71 y como IP de destino la IP del cliente interno. No debe haber ICMP Destination Unreachable.

  4. Prueba desde otro host
    Repite la consulta desde una máquina en una subred distinta dentro de la VPC para confirmar que la regla de resolver está propagada.

  5. Logs de VPC Flow
    Después de la prueba, revisa los logs; deberías ver tráfico REJECT → ACCEPT en los puertos 53 para las IPs involucradas.

Notas adicionales

  • Orden de reglas: en UniFi, las reglas de firewall se evalúan de arriba a abajo. Coloca la regla de DNS forwarding antes de cualquier regla de “deny all”.
  • Multiple Inbound Endpoints: si tienes más de un endpoint en distintas AZ, asegúrate de que el cliente reciba la IP más cercana; de lo contrario, el tráfico puede cruzar la VPC y volver a la VPN, generando latencia o pérdida.
  • Logs de Route 53 Resolver: habilita el registro de consultas para obtener visibilidad de qué consultas llegan al endpoint y cuál es la respuesta del resolver.
  • TTL bajo: durante la fase de pruebas, reduce el TTL de los registros a 60 seg para que los cambios de configuración se reflejen rápidamente.

Con estos pasos, la mayoría de los fallos de DNS en túneles Site‑to‑Site entre UniFi (o cualquier firewall) y AWS desaparecen. La clave está en alinear la IP de origen, abrir los puertos correctos y asegurarse de que la VPC tenga una regla de resolver que apunte al Inbound Resolver.