Firewall MikroTik блокирует легитимный трафик: сначала counters, потом правила

Короткий ответ

В RouterOS 7 правило filter — это не «логика на глаз», а счётчики. Пока не сняли /ip firewall filter print stats, не двигайте drop в конец и не ставьте accept на весь input. Легитимный трафик чаще всего ловят: connection-state=invalid, отсутствие established,related, accept только с неверного in-interface, и drop all, который оказался выше нужного accept.

Цепи разные: input — к самому роутеру (WinBox, DNS, WG listen), forward — транзит LAN↔WAN и LAN↔VPN, output — с роутера. Лечить «не открывается сайт» правкой input бесполезно.

Симптомы и как отличить

После добавления «безопасного» drop пропал интернет, или не ходит новый хост, или WireGuard handshake есть, а LAN за туннелем нет. WinBox при этом может жить — вы уже в established сессии.

Возможные причины

1. Default-like схема сломана: нет accept established,related в начале input/forward.
2. in-interface=ether1 вместо in-interface-list=LAN — после переименования порта правила «молчат» или наоборот ловят WAN.
3. action=drop connection-state=invalid косит асимметричный трафик (два WAN, ECMP, некорректный FastTrack+IPsec).
4. Accept нового протокола поставили ниже drop all.
5. fasttrack-connection выше accept для IPsec/WG — туннель «есть», payload нет.
6. Address-list опечатка, 192.168.88.1/24 как host вместо сети (в RouterOS 192.168.88.1/24 — сеть, 192.168.88.1 — хост; путают в WinBox).

Диагностика

/system backup save name=before-fw
/export file=before-fw
/ip firewall filter print stats
/ip firewall connection print count-only
/ip firewall connection print where src-address~"192.168.88."

1. Снимите counters в покое и под нагрузкой

Обнуление для чистого эксперимента:

/ip firewall filter reset-counters-all

Сразу воспроизведите проблему (пинг с ПК, открытие порта, handshake). Снова print stats. Правило, чей packets скакнул во время фейла — главный подозреваемый.

2. connection-state

В WinBox колонка State / в CLI:

/ip firewall connection print where protocol=tcp

Ищите invalid и полуоткрытые syn-sent. Много invalid при двух провайдерах — асимметрия, не «вирус».

3. Логирование точечно, не глобально

/ip firewall filter
add chain=forward action=log log-prefix=FWD-DROP connection-state=new in-interface-list=LAN place-before=[find chain=forward action=drop]

Не оставляйте log на каждый пакет: заполните RAM и память. После поимки — удалите log-правило.

4. Не путать NAT и filter

/ip firewall nat print с нулевыми stats при ненулевом drop forward — сначала filter. Наоборот: drop молчит, NAT молчит — маршрутизация.

Решение

Сценарий A. Сломали established,related

В начале input и forward (типичный каркас default config):

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment=defconf-est
add chain=input action=drop connection-state=invalid
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid

Порядок: accept established выше drop invalid и drop all.

Сценарий B. Новый сервис на роутере (WG, WinBox с определённой подсети)

Accept в input выше финального drop:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 comment=wg-in

Для WinBox/SSH не используйте in-interface=ether1 без нужды — см. hardening. Для LAN:

/ip firewall filter
add chain=input action=accept in-interface-list=LAN

Сценарий C. Транзит в VPN/другую LAN

Accept forward с in-interface=wg0 / out-interface=wg0 выше FastTrack и drop. Шаблон исключений — в статье про FastTrack.

Сценарий D. Нашли виновный drop

Не delete «все drop». Сузьте: добавьте accept с явным src-address=192.168.88.0/24 и dst-port, затем проверьте stats.

Как проверить, что проблема устранена

1. Counters на целевом accept растут во время рабочего трафика.
2. Counters на drop не растут на тех же пакетах (сбросьте counters и повторите один поток).
3. Функциональный тест: сайт, VPN, нужный порт.
4. С WAN-сканера не должны открыться 8291/22/80 — регресс безопасности недопустим.

/ip firewall filter print stats
/ip service print

Если не помогло

• Пакет не виден ни в одном правиле: raw/notrack или трафик не через этот CPU (switch chip offload на части моделей — смотрите /interface ethernet switch).
• Помогает disable всего filter — вы доказали вину firewall, не «интернета». Включайте правила пачками сверху вниз.
• IPv6: отдельная цепь /ipv6 firewall. Лечение только /ip firewall оставляет v6 дыру или наоборот блок.

Профилактика

• Комментарии comment= на каждом правиле.
• Изменения только в Safe Mode.
• Не копировать «полный drop-скрипт» из интернета поверх рабочей default-like схемы.
• Регулярный print stats: правило с нулями годами — кандидат на ошибку match.

FAQ

Нужно ли action=accept connection-nat-state=dstnat в forward?

В default defconf такое правило есть для проброса портов. Если делаете dstnat на сервер в LAN, без accept dstnat forward может дропнуть проброс. Это не замена accept из LAN в WAN.

Почему ping с WAN на 203.0.113.10 не проходит, а это «норма»?

Потому что ICMP на input с WAN в defconf часто ограничен. Открытие ping на WAN — отдельное решение, не диагностика LAN.

Можно ли поставить filter в pause (disabled) на ночь?

На время теста в простое — да, с пониманием, что WAN станет «дырявым», если нет внешнего NAT провайдера. Не оставляйте так.

connection-state=untracked зачем в accept?

Для пакетов из raw notrack. Если notrack не используете, established,related достаточно. Копировать untracked «на всякий» без raw не вредно в defconf, но не лечит drop.

Логи пишут drop, а stats на правиле ноль — как?

Смотрите другое правило с action=log или topic firewall от старого правила. Номера правил меняются после insert.