Клёвый Админ

action=passthrough

Что, простите? Это в какой документации вы такое прочитали?

Непонятные правила, с непонятно откуда взявшимися src-port, вы зачем это городите? Вам если нужен проброс портов через провайдера - дак вы его отдельно сделайте в NAT, но для начала настройте нормально, _по гайдам_ (не знаю как ещё крупнее выделить этот пункт) маршрутизацию.

Ну и чтоб закрепить

action=passthrough

значит буквально следующее - трафик посчитать, ничего с ним делать не нужно, пропустить дальше.

Тысячи раз решённая проблема. Hairpin-NAT вам нужен или замена DNS имени для локальных пользователей или DMZ с полноценной маршрутизацией и без проброса портов.
wiki.mikrotik.com/wiki/Hairpin_NAT

Конфиг вайфая экспортните сюда. Скорее всего что-то с частотами или каналами или буферами.

Какой ширины у вас канал? Хватает ли его полосы при полной нагрузке (не просаживаете ли вы вышестоящее устройство)?

Зачем на voip сделана очередь PCQ? Нужно юзать Default-small и задать в ограничениях ветки дерева максимальную полосу, с учётом всех возможных исходящих звонков (например 64k * 32 одновременных вызова), чтобы ветка могла в любой момент занять любое количество полосы, которое ей может потребоваться. Кажется, использование PCQ не оправданно.

Так же не видны на скриншоте приоритеты для остальных очередей, может там есть кто-то тоже с 1вым приоритетом.

Так же отмечу важный момент, очереди работают только для трафика который в них попал, они не учитывают всё что в них не попало, т.е. если торенты идут у вас где-то "мимо" (по скриншоту то не понятно), то QoS на них не распространится совсем.

И последнее, правила мангла для voip располагайте выше остальных, как бы отсеивая его сразу (passthrough=no) и маркируя только его, потом отмечайте что осталось другой, общей меткой

UPD поддержу Viktor, если у вас не куча зависимых сервисов, то можно справится через Simple правила и не городить mangle и деревья.

Ваше решение годное, из готового посмотрите вот это https://habrahabr.ru/company/selectel/blog/196620/
Так же советую использовать протокол RoMon, и центральный роутер (тот что сейчас на Windows) тоже на Mikrotik, а уже за ним любой backend, это даст больше свободы и возможностей по настройкам.

Создать адрес лист, с IP до этого сайта и добавьте разрешающее правило выше запрещающих.
Если все IP не известны, то добавьте в ДНС парочку статических записей.

Если я правильно смог в модели вашего железа (речь про свичи), то они у вас не управляемые, а значит не поддерживают нормальное разграничение по портам\vlan'ам.
В этом случае никакие vlan вам не нужны, делаете просто две отдельные l2 сети и отдельную адресацию для них, запрещаете трафик между ними либо роутами (как у вас), либо (что надёжнее) на уровне файрвола двумя drop правилами.

Бридж в данной конструкции не требуется, с тем же успехом адреса и правила firewall можно применять напрямую к пятому порту.

Алсо, отмечу, что в принципе возможна ситуация когда камеры умеют VLAN, тогда можно было бы на каждой камере настроить native vlan, затем добавить на master port виртуальный интерфейс с таким же vlan id и уже на этот VLAN интерфейс создать адресацию, роутинг и правила файрвола. Но опять же замечу, что в вашем случае (при наличии двух отдельных свичей, каждый для своей l2 сети) это излишне и тем более не безопасно, т.к. любой сможет принять трафик, прописав на интерфейса vlan id.

Провайдер что-то делает не так. Уточните у его ТП как так получилось что физическая среда разная, а сеть одна.

Если провайдер дал белые адреса и по "ту сторону" маршрутизатора у вас конкретные сервера (а не сети за NAT), то ваш маршрутизатор, ловким движением конфига, превращается в элегантный свич. *бриджуем порты, назначем серверам нужные адреса.

Если провайдер дал белые адреса и по "ту сторону" маршрутизатора у вас к сети с NAT за которыми у вас ПК, то просто указывайте в srcnat правилах нужные адреса, и маскируйте сеть нужными адресами.

Вы хотите слишком много телепатии.

Покажите ваши конфиги, поправить их будет куда проще. Если у вас есть в схеме NAT включите соотв опцию nat-traversal=yes, а из вашей статьи ориентируйтесь на часть под названием "Ipsec/L2TP behind NAT" там всё очень просто.

*Если роутер провайдерский, он может блокировать туннели или ipsec. Такое редко, но случается.

простая маршрутизация на внутренний (виртуальный) интерфейс на котором у микротика будет один IP (который для остальных хостов в этой сети будет шлюзом по-умолчанию) вас не устраивает? DMZ в чистом виде.

Для IP двойной нат - это костыль, для маршрутизатора - нагрузка, для админа - неразбериха, для клиентов - посра*ь.

Конструкция возможная, но маршрутизация всегда правильнее.

Если нужно собирать метаданные по трафику - совет рядом, если нужно брать прямо сам трафф аки СОРМ, то нужно зеркалить порт через настройки switch.

Показывайте конфиги