Кратко: проблема почти всегда в правилах firewall / в настройках DNS‑сервиса / в асимметричной маршрутизации. Чаще всего виновато либо то, что DNS‑сервер на 192.168.151.1 не принимает удалённые запросы или пакетам ответа мешает firewall/NAT, либо ответы приходят не тому устройству (ARP/NAT/асимметрия) и теряются.
Что проверить и сделать (пошагово)
1) Убедитесь, что сам роутер 192.168.151.1 действительно слушает DNS и разрешает удалённые запросы
- На MikroTik: /ip dns print
- Если allow-remote-requests = no — включите: /ip dns set allow-remote-requests=yes
2) Проверить, что на 192.168.151.1 открыт порт 53 для UDP и TCP (входящие запросы к самому роутеру)
- Посмотрите список правил: /ip firewall filter print
- Важное правило в начале цепочки INPUT: accept for established,related
Пример (добавить если нет):
/ip firewall filter add chain=input connection-state=established,related action=accept
- Разрешите DNS запросы из подсети:
/ip firewall filter add chain=input protocol=udp dst-port=53 src-address=192.168.151.0/24 action=accept comment="allow DNS UDP"
/ip firewall filter add chain=input protocol=tcp dst-port=53 src-address=192.168.151.0/24 action=accept comment="allow DNS TCP"
- Разрешите ICMP (чтобы пинг нормально работал):
/ip firewall filter add chain=input protocol=icmp action=accept
Обратите внимание на порядок правил — правило accept established должно стоять выше общих drop.
3) Проверьте NAT (маскарадинг)
- Посмотрите /ip firewall nat print
- Если есть правило src‑nat/masquerade, которое попадает на трафик внутри сети (например неправильно задан out-interface/chain), оно может менять исходный IP и ответы приходят не туда. В локальной сети src‑nat не должен применяться. Если сомневаетесь — опубликуйте правила nat.
4) Диагностика трафика (torch / sniffer)
- На 192.168.151.1 запустите torch на интерфейсе LAN и смотрите порт 53:
/tool torch interface=ether1 host=192.168.151.250 port=53
или быстрый сниффер:
/tool sniffer quick ip-protocol=udp host=192.168.151.250 and port=53
- На 192.168.151.250 тоже можно смотреть torch/sniffer, чтобы видеть, приходят ли ответы.
Это покажет: дошёл ли запрос на 151.1 и ушёл ли оттуда ответ (и с каким src/dst IP/MAC).
5) Проверка резолва прямо на роутере 192.168.151.250
- Выполните: /resolve yandex.ru
Если resolve использует неверный сервер — проверьте /ip dns на 250 (какой указан сервер) или настройки DHCP клиент/статического DNS.
6) Возможные частые причины, объясняющие «один пакет дошёл, остальные теряются»
- Асимметричный маршрут / ARP конфликт: конфликт MAC для IP/двойной настройки — проверьте /ip arp print и /ip neighbor print.
- Правило firewall допускает только первый пакет, а дальше пакеты помечаются как invalid и отбрасываются (нужна проверка connection-state и rules order).
- Ответ DNS большой: сначала UDP, затем TCP (например при больших ответах или DNSSEC). Если TCP 53 заблокирован — резолв падает.
- NAT/masquerade переписывает исходный адрес, сервер отвечает не тому хосту.
Резюме: наиболее вероятно — на 192.168.151.1 не хватает корректных правил INPUT (established/related + allow dst-port=53 tcp/udp), или есть неправильный NAT/ARP конфликт, из‑за чего ответы не доходят до 192.168.151.250. Выполните пункты 1–5, посмотрите вывод torch/sniffer и пришлите сюда вывод /ip firewall filter print, /ip firewall nat print, /ip dns print и результат /tool sniffer/torch — помогу точнее.