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

action=fasttrack-connection в forward для established,related вынимает пакеты из полного пути firewall/mangle/IPsec. Интернет через masquerade ускоряется, policy-based IPsec и часть WG-форварда перестают шифроваться или отвечать. Лечение — не «удалить FastTrack навсегда», а accept (без fasttrack) для VPN выше этого правила.

Проверка гипотезы: временно disable только fasttrack-правила. Если VPN ожил, гипотеза верна. Верните FastTrack и поставьте исключения, иначе CPU на NAT снова упрётся.

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

Классика: после применения defconf или «ускорения гигабита» site-to-site перестал пинговать LAN, IKE при этом established. Или WG last-handshake живой, файлы не копируются.

ТестВывод
FastTrack off → VPN onэта статья
FastTrack off → VPN всё ещё offмаршруты/ключи/policy
Нет FastTrack, CPU 100%, VPN окускоряйте LAN отдельно
Ломается только IPsec, WG окipsec-policy исключения

Не путайте с NAT masquerade: там counters srcnat нулевые. Здесь srcnat LAN-интернета жив.

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

  1. Defconf FastTrack выше любых VPN-accept.
  2. Исключения есть, но in-interface не тот (wg0 переименован).
  3. IPsec: нет ipsec-policy=in,ipsec / out,ipsec перед FastTrack.
  4. Mangle routing-mark на VPN-трафик не срабатывает из‑за FastTrack (policy routing + VPN).
  5. «Починили» удалением FastTrack и забыли — потом кто-то вернул defconf.

Диагностика

/ip firewall filter print stats
/ip firewall filter print where action=fasttrack-connection

Запомните номера. Safe Mode. Disable fasttrack на тест:

/ip firewall filter disable [find action=fasttrack-connection]

Проверьте ping LAN-LAN. Сразу включите обратно, если канал общий и CPU слабый — не оставляйте на день без исключений.

/ip firewall filter enable [find action=fasttrack-connection]

Для IPsec смотрите, растут ли SA counters при пинге. Нулевые при живом ping попытке — пакеты не входят в IPsec.

Решение

Порядок в forward (логика defconf + VPN):

  1. accept established,related с ipsec-policy=in,ipsec и out,ipsec (IPsec).
  2. accept in/out wg0 (WireGuard) для established и new.
  3. fasttrack-connection established,related.
  4. accept established,related (не fasttrack, для того что не попало).
  5. drop invalid.
  6. accept LAN→WAN и т.д.
  7. drop all.

Пример вставок выше fasttrack:

/ip firewall filter
add chain=forward action=accept connection-state=established,related ipsec-policy=in,ipsec comment=ft-excl-ipsec-in
add chain=forward action=accept connection-state=established,related ipsec-policy=out,ipsec comment=ft-excl-ipsec-out
add chain=forward action=accept connection-state=established,related,new in-interface=wg0 comment=ft-excl-wg-in
add chain=forward action=accept connection-state=established,related,new out-interface=wg0 comment=ft-excl-wg-out

place-before на id fasttrack-правила в вашей конфигурации обязателен: мало написать add в конец.

WinBox: перетащите строки выше зелёного FastTrack.

Для raw/notrack трюков с IPsec на ROS 7: не копируйте древние ROS 6 скрипты без чтения wiki текущей версии. Исключения filter достаточны в большинстве SOHO.

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

  1. FastTrack включён, counters растут на LAN-интернете.
  2. VPN ping/SMB живы параллельно.
  3. CPU не вернулся к 100% на гигабитном NAT (если модель тянула с FastTrack).
  4. После reboot порядок правил сохранился (/export в git/заявку).
/ip firewall filter print

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

  • Исключения есть, VPN нет: вернитесь к handshake/SA и маршрутам.
  • hw-offload на bridge съедает VLAN/IPsec на некоторых чипах — читайте ограничения модели, тест с hw-offload=no на fasttrack.
  • L2TP/IPsec, SSTP — свои интерфейсы, исключения по in-interface.
  • OpenVPN /interface ovpn-server — тоже не FastTrack'айте туннельный forward.

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

  • Любой новый VPN-интерфейс → сразу исключения FastTrack.
  • Комментарии ft-excl-*.
  • Не импортировать «голый defconf» поверх VPN без ревизии.
  • Нагрузка LAN и здоровье туннеля — два теста в чеклисте изменения firewall.
  • После insert правил снимите /ip firewall filter print в заявку: порядок выше FastTrack должен быть виден, не «вроде перетащили в WinBox».

Почему disable FastTrack «лечит», а удаление навсегда нельзя

FastTrack вынимает established из полного пути, где живёт IPsec policy и часть WG forward. Поэтому A/B с disable — честный тест, но на слабом CPU гигабитный NAT без FastTrack снова упрётся. Исключения должны стоять выше правила fasttrack-connection, иначе они мёртвый код.

Для IPsec недостаточно in-interface=ether1: нужен matcher ipsec-policy=in,ipsec и out,ipsec на established,related. Для new в удалённую LAN добавьте accept по dst-address=192.168.10.0/24 выше FastTrack, если видите, что первый пакет не шифруется.

/ip firewall filter print where chain=forward

Проверьте номера после каждого insert: WinBox и CLI по-разному сдвигают id. После reboot порядок должен сохраниться — снимите /export фрагмент filter в заявку. hw-offload=yes на части чипов с vlan-filtering ведёт себя иначе; если VPN ожил только при hw-offload=no, оставьте FastTrack, но снимите offload, и измерьте CPU на LAN-NAT отдельно.

Не ставьте FastTrack на connection-state=new. Не FastTrack'айте connection-mark policy-routing, если марки должны жить всю сессию.

FAQ

Почему MikroTik так сделал?

FastTrack — короткое замыкание для массового NAT. IPsec нужен полный path. Это документированное поведение, не баг вашей сборки.

Можно ли FastTrack только для WAN, не для wg0?

Именно это и делают matchers на in/out interface и ipsec-policy. FastTrack правило без matchers хватает всё established.

Нужен ли accept new для IPsec до FastTrack?

Для первого пакета new обычно идёт обычным путём; ломаются established, которые попали в FastTrack. На практике ipsec-policy на established,related — ключ. New LAN→удалённая сеть должен шифроваться policy до fasttrack тоже; если new не матчится ipsec-policy, добавьте accept по dst-address удалённой LAN выше FastTrack.

connection-nat-state?

Для dstnat пробросов, не для site-to-site. Не путайте.

Отключить hw-offload, оставить FastTrack?

Иногда да, на проблемных VLAN+bridge. Тестируйте скорость и VPN раздельно.

Нужно ли исключать L2TP/IPsec и OVPN тем же способом?

Да по смыслу: любой туннельный forward, которому нужен полный path (шифрование, mangle MSS, routing-mark), не должен попадать в fasttrack-connection. Для l2tp-out/ovpn-in ставьте accept in/out этого интерфейса выше FastTrack. Для policy IPsec интерфейса нет — только ipsec-policy. Проверяйте A/B disable FastTrack по каждому типу VPN отдельно: «WG ожил, IPsec нет» значит исключили только wg0. Не удаляйте FastTrack для LAN-NAT: верните его под исключениями.