Проблемы с перенаправлением портов

Отличный ответ. Второй обратный путь — вот чего мне не хватало в настройках. Спасибо за пост!

Логика пропускать посылки в офис, а потом уже проверять, опасны ли они, даже если там бомба — однозначно хуже, чем сразу запрещать посылки, если их не заказывали. Проще говоря, лучше сразу блокировать пакет в RAW, вместо того чтобы по восемь раз зря его обрабатывать на всех этапах, пока он не дойдет до Firewall Filter.

Или проще, как вообще обрабатывается пакет? https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS#PacketFlowinRouterOS-FlowofRoutedPacket  
Сначала проход через RAW, потом Connection-Tracking, Prerouting-Mangle, DST-NAT, Routing, управление TTL, Forward-Mangle, и наконец Forward-Filter и так далее.

Если блокировать пакет на этапе RAW, он не проходит следующие 7 шагов. Если же блокировать пакет на Filter, он уже прошел RAW, Connection-Tracking, Mangle, DST-NAT, Routing, TTL, снова Mangle и только потом Firewall Filter. Нет никакого смысла блокировать нежелательные соединения в конце этого восьмиэтапного процесса — лучше сделать это сразу.

Да, конечно, удалить всё в конце — вариант, но если точно известно, что какой-то трафик не нужен, лучше блокировать его сразу, а не тратить зря ресурсы, время и мощность на его обработку.

Если внимательно анализировать заблокированный трафик, можно понять, как создать правила в RAW, которые полностью остановят ненужный трафик ещё до того, как система начнёт его обрабатывать.

Пример наглядный: черные списки надо блокировать в RAW, а не в фильтре. Иначе пакеты обрабатываются восемь раз перед тем, как попасть в Firewall Filter (входящий трафик или форвард — без разницы).

С точки зрения безопасности ваша логика безупречна. С точки зрения производительности — не очень. Да, безопасность должна быть на первом месте, но если можно оптимизировать систему без потери безопасности, то разумно это сделать. Можно сравнить RAW-фильтр с проверками безопасности, которые выполняются для каждого пакета. А фильтр файрвола — с проверками безопасности только для пакетов, которым на данном этапе не доверяют.  

Теперь представьте: у вас в почтовом отделении приходит миллионы писем. Если безопасность проверять прямо на входе, бедный охранник должен будет досмотреть каждое письмо, и можно представить, сколько у него работы, даже если проверка занимает совсем немного времени. Поскольку охранник обычно отклоняет очень мало писем, остальные процессы не выигрывают от этого, но работать ему приходится изо всех сил.  

Если же, с другой стороны, письма сначала проходят сортировочную машину (connection tracking), и большая часть писем пропускается без проверки (потому что… как-то… им доверяют) — например, established, related, untracked — а проверки безопасности делаются только с оставшимися единичными письмами, то охранник работает гораздо меньше.  

Но тут заканчивается параллель — в файрволе это на самом деле один и тот же человек (или очень мало людей… то есть CPU-ядер), которые выполняют все операции. Если этот человек не будет делать базовые проверки безопасности для каждого входящего пакета, а только для тех, которым не доверяют, он сможет больше времени уделить сортировке и остальной обработке, и общее количество обработанных пакетов окажется выше, чем в первом случае.  

Конечно, бывают ситуации (например, DDoS), когда выгоднее удалять опасные пакеты прямо при входе (из-за огромного количества пакетов, которые отклоняет охранник), но в обычных условиях — нет.

Ответ был вызван кем-то, кто постоянно критикует RAW.