Введение в Layer 3 Firewall MikroTik
Firewall (или пакетный фильтр) — это большая и сложная тема как в теоретическом, так и в практическом плане. Пакетный фильтр в различных операционных системах может иметь свои плюсы и минусы по сравнению с другими реализациями. В данной статье я буду рассматривать исключитетльно Firewall в RouterOS с оглядкой на его прародителя iptables.
Предисловие
Для кого эта статья
Если вы умеете работать с iptables, то дерзайте и настраивайте firewall, для вас в этой статье не будет ничего нового (ну разве что в таблице NAT используются цепочки с другими именами). Если вы впервые видите firewall в RouterOS и хотите получить готовый скрипт для конфигурации, то вы его здесь не найдете. Материал нацелен на тех, кто хочет получить базовое представление о том как работает firewall и что происходит с ip пакетом на разных этапах его обработки. Более глубокое понимание прейдет с опытом и решением повседневных и необычных задач с использованием пакетного фильтра.
Теоретическая часть
Что такое Layer3 Firewall
Предположим, что у вас есть роутер с выходом в интернет и двумя bridge интерфейсами: bridge-lan (ether2-ether5) и bridge-dmz (ether6-ether10).
В пределах Bridge интерфейса устройства самостоятельно находят соседей из свой подсети и обмениваются пакетами, роутер выполняет функции свича и не отслеживает такой трафик на сетевом уровне (конечно можно принудительно заставить его это делать, но про Layer2 Firewall поговорим в другой раз).
При необходимости связаться с устройством подключенного к другому bridge интерфейсу или находящемуся в глобальной сети устройства передают пакеты маршрутизатору, который определяет маршрут следования и обрабатывает их на сетевом (Layer 3) уровне.
Packet Flow Diagram
Полный путь трафика описан в Packet Flow Diagram, есть несколько официальных (v5, v6) версий, их необходимо знать и использовать в повседневной работе, но для понимания работы пакетного фильтра они перегружены, поэтому я буду объяснять на облегченном варианте.
Input/Output Interface — это любой (физический или виртуальный) Layer 3 интерфейс роутера. Пакет который идет из локальной сети в интернет попадает на input interface, а уходит с output interface. Пакет из интернета в локальную сеть, также попадает на input interface, а уходит с output interface. Packet Flow всегда читается в одном направлении input → output.
Особенности терминологии
Изучая packet flow для iptables, можно встретить описания через «цепочки в таблицах» либо «таблицы в цепочках». На схеме представлены таблицы в цепочках, при добавлении правил в firewall все будет наоборот.
Но на самом деле пакет перемещается между блоками [цепочка+таблицы], например если вы сделайте accept в блоке [prerouting+mangle] транзитный пакет все-равно будет обработан в [forward+mangle]. Это важно помнить в сложных конфигурациях с pbr и queues.
В документации iptables есть более точные определения, но простыми словами:
Цепочки отвечают за место обработки пакета и последовательность правил.
Таблицы определяют действия, которые можно произвести над пакетом.
Базовые варианты следования пакета
Транзитный
- Пакет из сети приходит на один из интерфейсов роутера
- В цепочке PREROUTING администратор может повлиять на маршрут следования пакета: определить выходной интерфейс (Policy base routing) или перенаправить на другой адрес (dst-nat).
- В соответствии с таблицей маршрутизации для пакета определяется исходящий интерфейс.
- Цепочка FORWARD — основное место фильтрации проходящего трафика.
- Последним пунктом перед выходом в сеть является цепочка POSTROUTING, в которой можно изменить адрес отправителя (src-nat).
- Пакет ушел в сеть.
Входящий
- Пакет из сети пришел на один из интерфейсов роутера
- Попал в цепочку PREROUTING.
- В соответствии с таблицей маршрутизации пакет был отправлен на обработку локальному процессу.
- В цепочке INPUT происходит фильтрация входящего трафика администратором.
- Пакет ушел на обработку локальному процессу.
Исходящий
- Один из процессов роутера сгенерировал ip пакет (новый или ответный — неважно).
- В соответствии с таблицей маршрутизации для пакета определен выходной интерфейс.
- Администратор может фильтровать исходящий трафик, либо изменять маршрут в цепочке OUTPUT.
- Для пакета принимается окончательное решение о выходном интерфейсе.
- Пакет попадает в POSTROUTING, как и проходящий трафик.
- Пакет ушел в сеть.
Connection Tracker
Для начала необходимо понять, что представляет из себя stateful и stateless пакетные фильтры.
Пример. Компьютер 192.168.100.10 открывает tcp соединение с сервером 192.0.2.10. На стороне клиента используется динамический порт 49149, на стороне сервера 80. Еще до получения контента клиент и сервер должны обменяться пакетами для установки tcp сессии.
В stateless потребуется открыть трафик из локальной сети в интернет и из интернета в локальную сеть (как минимум для диапазона динамических портов). Что в целом является дырой.
В stateful маршрутизатор анализирует пакеты и получив tcp syn от 192.168.100.10:49149 для 192.0.2.10:80 считает это началом нового (new) соединения. Все дальнейшие пакеты (в любом направлении) между 192.168.100.10:49149 и 192.0.2.10:80 будут считаться частью установленного (established) соединения, до закрытия tcp сессии или истечения таймеров.
Для UDP/ICMP и других видов трафика, где нельзя четко выделить начало и конец соединения, новым пакетом является первый, остальные считаются частью установленного соединения и обновляют таймеры, маршрутизатор забывает про подобные соединения по истечению таймеров.
Connection tracker делит пакеты на несколько типов: 
new — пакет открывающий соединение, например syn для tcp или первый пакет в udp потоке.
established — пакет относящийся к известному соединению.
related — пакет относящийся к дополнительному соединению в мультипротоколе (sip, pptp, ftp, …).
invalid — пакет от неизвестного соединения.
untracked — пакет не отслеживаемый connection tracker.
Конфигурация Connection tracker
enabled=yes — включен.
enabled=no — отключен.
enabed=auto — отключен, пока в firewall не появится правило использующее возможности conntrack. Используется по умолчанию.
Остальные параметры являются различными таймерами и обычно не требуют тюнинга.
Администратор может просматривать и удалять соединения, например так выглядит соединение с NAT: 
Использование conntrack сказывается на производительности и потреблении ресурсов (особенно при большом числе соединений), но отключить его в большинстве конфигураций не получится, т.к. у вас останется stateless firewall без NAT.
TTL
Time To Live — поле в заголовке IP пакета определяющее число маршрутизаторов через которые может пройти пакет прежде чем будет уничтожен, защищает от бесконечной пересылки пакетов при петлях маршрутизации.
При пересылке (forwarding) роутер уменьшает значение TTL на 1 отбрасывает, если TTL=0. При этом пакет с TTL=1 попадет локальному процессу роутера.
Некторые операторы связи используют трюки с TTL для пресечения использования роутеров. Все эти ограничения прекрасно обходятся увеличением значения ttl в таблице mangle.
NAT
Network Address Translation — технология изменения адресов в заголовке ip пакета. Как и в linux, NAT является частью пакетного фильтра. NAT работает на основе connection tracker.
Изначально NAT был разработан как быстрое решение проблемы исчерпания IPv4 адресов, для локальных сетей было предложено использовать подсеть из диапазонов: 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16 и транслировать их в один (или несколько) маршрутизируемых адресов. На самом деле есть еще несколько служебных подсетей, которые можно использовать в частных сетях и роутеру в принципе все-равно что и как NAT’ить, но рекомендуется следовать стандартам.
NAT обрабатывает только: tcp, udp, icmp и некоторых мультипротоколов из [IP]→[Firewall]→[Service Port]. Обрабатывается только первый (connection-state=new) пакет в соединении, оставшиеся обрабатываются автоматически без участия таблицы NAT. Это можно отследить по изменению счетчиков в правилах.
В заголовке пакета присутствует Source и Destenation address, соответственно и NAT делится на Source и Destenation NAT.
Source NAT — подмена адреса отправителя, присутствует на подавляющем большинстве домашних и корпоративных роутеров в мире.
Позволяет множеству устройств с «серыми» адресами в локальной сети общаться с интернетом используя один (или несколько) реальных адресов.
Возвращаясь к Packet Flow смотрим, что SRC-NAT находится в Postrouting, после принятия решения о маршрутизации пакета.
Ответный пакет проходит неявный DST-NAT в котором адрес получателя меняется на локальный.
Destenation NAT — подмена адреса получателя.
Применяется при необходимости переслать пакет на другой адрес, обычно используется для «проброса портов» из внешней сети в локальную.
По Packet Flow работа DST-NAT происходит до принятия решения о маршрутизации в Prerouting, присутствует неявный SRC-NAT для ответного трафика.
NAT является довольно мощным инструментом управления трафиком, но применять его стоит в последнюю очередь (когда остальные инструменты не могут помочь).
Цепочки (chains) базовые и пользовательские
Цепочки состоят из правил и форсируют логику обработки пакета.
Есть несколько базовых цепочек, отображенных на packet flow:
Prerouting (dstnat) — обработка пакета до принятия решения о маршрутизации
Input — обработка пакетов предназначеных локальным процессам маршрутизатора
Output — обработка пакетов пакетов сгенерированных локальными процессами маршрутизатора
Forward — Обработка проходящего трафика
Postrouting (srcnat) — Обработка трафика готового к передаче на интерфейс
Все как в iptables, но цепочки в nat переименованы. С чем это связано (скорее всего с hotspot или аппаратной разгрузкой nat) мне неизвестно, но в корне ничего не меняет.
Пакет проходит правила в цепочке последовательно, если он подходим по всем условиям, то к пакету применяется действие. Если действие является терминирующим и не отбрасывает пакет, то он передается в следующий блок packet flow.
У всех цепочек базовых есть действие по умолчанию (если пакет не подошел ни под одно из правил) — accept.
Пользовательские цепочки необходимы для уменьшения количества правил которые проходит каждый пакет и для построения сложных правил обработки трафика. У всех пользовательских цепочек есть действие по умолчанию — return.
В пределах таблицы можно пересылать правила из нескольких различных базовых (и пользовательских) цепочек в пользовательскую, но вернется пакет в ту цепочку из которой пришел.
Условия в правилах
Цепочки состоят из правил, каждое правило состоит из условий и действия. Условий достаточно много, но далеко не все вы будете использовать в реальных конфигурациях. Большинству условий можно поставить префикс «не» (знак »!»). Для совпадением с правилом, пакет должен подходить под все указанные условия.
| Условие | Описание |
|---|---|
| src-address | Адрес источника |
| dst-address | Адрес получателя |
| src-address-list | Адрес источника присутствует в списке |
| dst-address-list | Адрес получателя присутствует в списке |
| protocol | Протокол транспортного уровня |
| src-port | Порт источника |
| dst-port | Порт получателя |
| port | Порт источника или получателя |
| in-interface | Интерфес на который пришел пакет |
| out-interface | Интерфейс с которого пакет будет отправлен в сеть |
| in-interface-list | Интерфес на который пришел пакет присутствует в списке |
| out-interface-list | Интерфейс с которого пакет будет отправлен в сеть присутствует в списке |
| layer7-protocol | Анализ содержимого первых 10 пакетов в соединениий |
| content | Поиск заданной строки в пакете |
| tls-host | Поиск хоста в заголовке tls |
| ipsec-policy | Проверить подпадает пакет под политику ipsec или нет |
| packet-size | размер пакета в байтах |
| src-mac-address | mac адрес источника пакета |
| connection-mark | Метка соединения |
| packet-mark | Метка пакета |
| routing-mark | Маршрутная метка пакета |
| connection-state | Состояние пакета в соединении |
| tcp-flags | Флаги tcp пакета |
| icmp-options | Опции icmp пакета |
| random | Правило срабатывает (при совпадении остальных условий) с заданной вероятностью |
| time | Можно указать рабочее время правила, к сожалению без конктеризации даты |
| ttl | Значение поля ttl в пакете |
| dscp | Значение поля DSCP (ToS) в пакете |
| --//-- | --//-- |
| place-before | Консольная опция (не условие), позволяет добавить правило перед указанным |
| disabled | Консольная опция (не условие), позволяет отключить правило |
Примечания
В качестве src.(dst.) address можно указывать: одиночный ip, диапазон адресов через дефис, либо подсеть.
Списки адресов необходимы для объединения под одним именем нескольких несвязанных ip. В отличии от ipset в netfilter, записи в списках MikroTik могут удаляться через заданный промежуток времени. Просмотреть списки и внести изменения можно в [IP]→[Firewall]→[Address Lists].
В качестве номера порта (port, src-port, dst-port) можно указывать одиночный порт, несколько портов через запятую, либо диапазон портов через дефис.
На последнем MUM в МСК была неплохая презентация на тему влияния различных условий на скорость обработки пакетов (там же вы узнаете как использовать таблицу raw для снижения нагрузки на роутер), кому интересно: запись и презентация.
Действия в таблицах
Набор доступных действий над пакетом, зависит от таблицы в которой он обрабатывается.
Filter — таблица фильтрации трафика, одно из двух мест, где можно отбросить пакет.
NAT — таблица модификации ip адресов и портов (tpc, udp) в заголовке ip пакета.
Mangle — таблица для модификации других полей ip пакета и установки различных меток.
Существует три типа внутренних меток пакетов: connection, packet, route. Сетки существуют только в пределах роутера и не уходят в сеть. Пакет может иметь по одной метке каждого типа, при последовательном прохождении нескольких mark-* правил метки перезаписываются.
Маршрутные метки можно ставить только в цепочках prerouting и output, остальные в любых цепочках.
Хорошей практикой считается сначала маркировать соединение (connection), а потом пакет (packet) либо маршрут (route). Проверка наличия метки происходит быстрее чем полей пакета. На практике, это не всегда так и в сложных очередях или pbr дополнительная маркировка соединения не приносит пользы.
RAW — таблица позволяющая пакетам обходить механизм трекинга соединений (connection tracker). Используется для противодействия DoS и снижения нагрузки на cpu (например исключением multicast трафика). Позволяет отбросить пакет.
Терминирующие действия завершают обработку пакета в цепочке и передают следующему блоку в packet flow, либо отбрасывают.
| Таблица | Действие | Описание | Терминирующее? |
|---|---|---|---|
| Все | accept | Прекратить обработку пакета и передать в следующий блок Pakcet flow | Да |
| Все | log | Записать в log информацию о пакете.В современных версиях можно добавить log к любому другому действию | Нет |
| Все | passtrough | Посчитать число пакетов. Используется для отладки | Нет |
| Все | add src to address list и add dst to address list | Добавить source (destenation) адрес из пакета в заданный список | Нет |
| Все | jump | Перейти в пользовательскую цепочку | Да |
| Все | return | Вернуться в родительскую цепочку. В базовых цепочках работает как accept | Да |
| Filter и Raw | drop | Остановить движение пакета по packet flow и отбросить | Да |
| Filter и Prerouting | fasttrack | Пометить пакет для быстрого прохождения packet flow | Да |
| Filter | reject | Аналогично drop, но отправителю пакетов отправляется уведомление (tcp или icmp) о отброшенном пакете | Да |
| Filter | trapit | Эмулировать наличие открытого порта. Используется для защиты от DoS, ввода в заблуждение и (иногда) отладке | Да |
| NAT | src-nat | Подмена адреса отправителя на указанный | Да |
| NAT | masquerade | Частный случай src-nat, подменяет адрес отправителя на один из адресов с интерфейса, используется на динамических (dhcp, vpn) интерфейсах. Не рекомендуется использовать при наличии нескольких ip на интерфейсе | Да |
| NAT | same | Частный случай src-nat. Подменяет адрес отправителя на адрес из заданного диапазона | Да |
| NAT | dst-nat | Подменяет адрес получателя на указанный | Да |
| NAT | redirect | Частный случай dst-nat, подменяет адрес получателя на адрес интерфейса роутера на который пришел пакет | Да |
| NAT | netmap | Не замена dst-nat. Применяется при трансляции сеть-в-сеть, смотрите примеры | Да |
| Mangle | mark connection | Метка соединения | Нет |
| Mangle | mark packet | Метка пакета, применяется в очередях | Нет |
| Mangle | mark routing | Метка маршрута, применяется в Policy base routing | Нет |
| Mangle | change ttl | Изменить ttl | Нет |
| Mangle | change dcsp (tos) | Изменить dcsp, в десятичном виде | Нет |
| Mangle | change mss | Изменить mss в tcp syn | Нет |
| Mangle | clear df | Очистить флаг do not fragmet | Нет |
| Mangle | strip ipv4 options | Очистить дополнительные опции ipv4 | Нет |
| Mangle | set priority | Установить приоритет для CoS | Нет |
| Mangle | route | Задать gateway для пакета. Простая версия PBR | Нет |
| Mangle | sniff tzsp | Инкапсулировать пакеты в udp и отправить на указанный ip | Нет |
| Mangle | sniff pc | Аналог tzsp, но с другим типом инкапсуляции. В wiki если примеры использования с calea | Нет |
| Mangle | passtrough | По умолчанию большинство правил в mangle не останавливает прохождение пакета, можно изменить это поведение установить passtrough=no | Нет |
| Raw | notrack | Не отслеживать пакет в connection tracker | Да |
Если найдутся желающие, могу написать подробнее про FastTrack и FastPath, но чудес от этих технологий ждать не стоит.
Пара слов про DPI
Существует несколько возможностей заглядывать в пакет чуть глубже заголовка транспортного уровня:
content — производит поиск заданной строки в пакете.
layer7-protocol — буферезирует первые 10 пакетов (или 2KiB) из соединения и производит поиск по regexp в буферезированных данных. Большое число layer7 правил существенно влияют на производительность.
tls-host — адрес имени хоста в заголовке TLS/SNI соединения HTTPS.
Примеры
Не копируйте примеры бездумно, лучше возбмите устройство и постарайтесь написать конфигурацию самостоятельно (или переписать примеры, но вникнуть что делает каждое из правил). Если не знаете как дополнить правила: в дефолтной и минимальной домашней конфигурациях нет доступа на роутер с wan интерфейса, добавьте его с фильтрацией по списку адресов.
Дефолтный Firewall RouterOS
Достаточно защищенная конфигурация, но местами сильно замороченая:
/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений и неотслеживаемые(untracked) пакеты
add action=accept chain=input connection-state=established,related,untracked
#Отбрасываем входящие пакеты от неизвестных(invalid) соединений
add action=drop chain=input connection-state=invalid
#Разрешаем входящий icmp трафик
add action=accept chain=input protocol=icmp
#Отбрасываем все входящие пакеты пришеджие не с интерфейсов локальной сети
add action=drop chain=input in-interface-list=!LAN
#Для правильной работы ipsec в туннельном режиме
add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec
#Маркируем для быстрого прохождения транзитные пакеты от уже установленных соединений
add action=fasttrack-connection chain=forward connection-state=established,related
#Разрешаем транзитные пакеты от уже установленных соединений
add action=accept chain=forward connection-state=established,related,untracked
#Отбрасываем неизвестные транзитные пакеты
add action=drop chain=forward connection-state=invalid
#Отбрасываем транзитные пакеты со стороны wan интерфейсов, которы не относятся к dstnat (вспоминаем, что для ответных пакетов в src-nat присходит неявный dst-nat)
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
#Source NAT для пакетов не относящихся к ipsec, уходящих с интерфесов из списка WAN
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
Никогда не использовал дефолтный конфиг, но раньше дефолтный firewall был значительно хуже.
Минимальный «домашний» firewall
Самый простой, что удалось придумать. Да в нем не разрешен untracked трафик (но на этапе базового изучения firewall он вам всеравно не нужен) и будут проблемы с туннельным ipsec (опять-же, если вы умеете настраивать ipsec, то сами знаете что необходимо сделать).
/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений
add chain=input connection-state=established,related action=accept
#Разрешаем входящий icmp трафик
add chain=input connection-state=new protocol=icmp action=accept
#Разрешаем входящий трафик из локальной сети
add chain=input connection-state=new in-interface-list=LAN action=accept
#Отбрасываем весь оставшийся входящий трафик
add chain=input action=drop
#Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward connection-state=established,related action=accept
#Разрешаем транзитные пакеты из локальной сети в сеть интернет
add chain=forward connection-state=new in-interface-list=LAN action=accept
#Отбрасываем весь оставшийся транзитный трафик
add chain=forward action=drop
/ip firewall nat
#Source NAT для пакетов уходящих с интерфесов из списка WAN
add chain=srcnat out-interface-list=WAN action=masquerade
Пример с DMZ
На «домашних» роутерах аббревиатурой DMZ любят обзывать компьютер в локальной подсети для которого проброшены все порты из внешней сети.
На самом деле это не так и один из вариантов DMZ — отделение ресурса на который необходимо предоставить доступ из сети интернет и может быть проведена успешная атака (web server с cms в которых постоянно находят дыры — хорошая цель для взломщика). В случае взлома, злоумышленник не сможет повлиять на участников локальной сети.
#Проброс порта
/ip firewall nat
add chain=dstnat dst-port=80,443 action=dst-nat to-address=192.168.200.2
/ip firewall filter
#Разрешаем ответный и icmp входящий трафик
add chain=input connection-state=established,related action=accept
add chain=input protocol=icmp connection-state=new action=accept
#Разрешаем входящий трафик из локальной сети
add chain=input in-interface=ether2-lan action=accept
#Отбрасываем оставшийся входящий трафик
add chain=input action=drop
#Разрешаем ответный транзитный трафик
add chain=forward connection-state=established,related action=accept
#Разрешаем пользователям из локальной сети создавать транзитные соединения
add chain=forward in-interface=ether2-lan connection-state=new action=accept
#Разрешаем транзитные соединения на web сервер
add chain=forward out-interface=ether3-dmz dst-address=192.168.200.2 dst-port=80,443 connection-state=new action=accept
#Отбрасываем оставшийся транзитныйтрафик
add chain=forward action=drop
HairPin NAT
/ip firewall mangle
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2
Типичная ситуация, когда вы делайте проброс порта на сервер в локальной сети и извне все работает, а вот внутри локальной сети сервер не доступен по внешнему адресу.
Давайте разберем что происходит:
- Компьютер 192.168.100.10 отправляет запрос на 192.0.2.100
- На роутере отрабатывает DST-NAT и пакет пересылается на 192.168.100.2
- Сервер видит, что к нему на адрес 192.168.100.2 пришел пакет от 192.168.100.10 и отвечает 4. Компьютер получает неожиданный пакет от 192.168.100.2 и отбрасывает его.
Решение — добавить дополнительное правило изменяющее адрес источника на адрес роутера, таким образом сервер вернет пакет на роутер, который отправит его на компьютер инициализатор.
/ip firewall mangle
#Правило проброса
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2
#Новое правило, для пользователей из локальной сети
add chain=srcnat src-address=192.168.100.0/24 dst-address=192.168.100.2 action=masquerade
На практике такую схему используют не часто, но как пример отладки firewall мне очень нравится.
Правильное использование netmap
Netmap — технология трансляции адресов из одной подсети в адреса другой подсети.
IP адрес (в записи с маской) состоит из двух частей: сетевой (число бит указанных в маске подсети) и хостовой (оставшиеся биты). Netmap изменяет сетевую часть адреса, но не трогает хостовую.
Есть два роутера соединенные VPN каналом. Роутеры обслуживают подсети с одинаковой адресацией. Необходимо сделать доступ между подсетями.
Без дополнительной адресации тут не обойтись.
Пользователи из левой подсети будут стучаться в правую через подсеть 192.168.102.0/24
Пользователи из правой подсети будут стучаться в левую через подсеть 192.168.101.0/24
Конфигурация на MikroTik 1.
#Без правила роутинга не обойтись
/ip route
add distance=1 dst-address=192.168.102.0/24 gateway
/ip firewall nat
#В исходящих пакетах будем менять адрес источника
add action=netmap chain=srcnat dst-address=192.168.102.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.101.0/24
#Во входящих пакетах будем менять адрес получателя
add action=netmap chain=dstnat dst-address=192.168.101.0/24 in-interface=ipip src-address=192.168.102.0/24 to-address=192.168.100.0/24
Конфигурация MikroTik2 практически аналогична:
/ip route
add distance=1 dst-address=192.168.101.0/24 gateway=10.10.10.1
/ip firewall nat
add action=netmap chain=srcnat dst-address=192.168.101.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.102.0/24
add action=netmap chain=dstnat dst-address=192.168.102.0/24 in-interface=ipip src-address=192.168.101.0/24 to-address=192.168.100.0/24
Есть более сложные конфигурации с использованием netmap, например если у вас множество подключений к удаленным точкам с пересекающимеся подсетями и нет возможности изменить настройки на удаленном оборудовании, но это уже advanced routing.
Если вы ничего не поняли (про netmap), значит оно вам не нужно и просто не используйте данное действие при пробросе портов.
