# Не работает DNAT или порт-форвардинг
# Симптомы

*Не работает правило DNAT или Port Forwarding.
При включении Журналирования на правиле в Журнале трафика нет событий.*

# Решение

Проблема может быть связана по одной или нескольким причинам:

1\) Наличие шлюза в локальную сеть, в которую настроен DNAT. В NGFW есть внутренняя настройка, для перенаправления ответного трафика от ресурсов, опубликованных через правила DNAT в сторону шлюза, с MAC адреса которого пришел запрос, это нужно для случая, если используется несколько провайдеров и на них включен ip-spoofing, но если создан шлюз в сторону локальной сети и за ним находится публикуемый ресурс это приведет к тому, что ответные пакеты с NGFW будут перенаправлены обратно в локальную сеть.

<u>Отключить или удалить шлюз в локальную сеть, а затем создать статический маршрут к публикуемому серверу.</u>

2\) У публикуемого сервера шлюзом по умолчанию является не Usergate. В таком случае ответные пакеты он отправляет в сторону своего шлюза по умолчанию, из-за чего соединение не устанавливается.

<u>Активировать в свойствах правила DNAT галку "Включить SNAT", либо назначить публикуемому серверу шлюзом по умолчанию адрес Usergate. </u>

3\) Трафик блокируется одним из правил Межсетевого экрана. При этом направление запрещающего правила может как совпадать с направлением правила DNAT, так и быть ровно обратным. Например если DNAT настроен из зоны Untrusted в Trusted, то правило МСЭ, запрещающее трафик для публикуемого сервера в обратную сторону из зоны Trusted в Untrusted может блокировать ответные пакеты. Для фиксации данного поведения можно включить на запрещающем правиле "Журналирование всех пакетов", сгенерировать трафик и проверить журналы по внутреннему адресу источника сервера.

<u>Создать разрешающее правило МСЭ для публикуемого сервиса и разместить его выше блокирующего правила.</u>

4\) В публикуемом сервисе указаны порты источника.&#x20;

При создании Сервиса необходимо учитывать, что порты назначения - это те порты, которые вы хотите пробросить, а <u>порты источника нужно оставить пустыми</u>, так как они зачастую случайным образом выбираются клиентом.

5\) Выполнить ping к публикуемому ресурсу с внутреннего интерфейса. Записать дамп на внешнем и внутренних интерфейсах, адреса которых задействовать в правиле DNAT, и проверить, проходят ли к нему пакеты в момент выполнения проверки доступности порта или пакеты ICMP.

6\) Удостоверится, что <u>в используемых списках IP присутствуют необходимые IP-адреса</u>, для которых настраивается правило.

7\) Трафик не проходит через правило DNAT из-за разных драйверов на интерфейсах, через которые он проходит к публикуемому серверу. Отключить модуль Fastpath согласно данной статье [https://sd.usergate.com/articles/14](https://sd.usergate.com/articles/14) и затем проверить работу правила.

8\) Для публикации FTP через DNAT необходимо выполнить рекомендации из статьи - [https://sd.usergate.com/articles/2683](https://sd.usergate.com/articles/2683)

9\) При публикации веб-сервера по HTTP или HTTPS через DNAT на внешнем IP адресе открывается заглушка UserGate.

Соединение запрещается правилом контентной фильтрации (включите журналирование во всех запрещающих правилах и посмотрите в журнале веб-доступа каким правилом блокируется соединение).
Необходимо или <u>создать явное разрешающее правило ФК выше или изменить данное правило</u> (например внести в адрес назначения IP внутреннего сервера или доменное имя, на которое вы соединяетесь, в исключения).

10\) Для публикуемого ресурса используются зарезервированные для локальных сервисов Usergate порты.

<u>Проверить отсутствие указанного в правиле DNAT порта (либо диапазона портов) в таблице</u> - [https://docs.usergate.com/trebovaniya-k-setevomu-okruzheniyu\_1349.html](https://docs.usergate.com/trebovaniya-k-setevomu-okruzheniyu_1349.html)&#x20;

Например, порты 2200, 8001, 4369, 9000-9100 можно использовать в правилах DNAT, если на зоне источника не включён сервис, используемый данные порты. Например согласно таблицы - [https://docs.usergate.com/trebovaniya-k-setevomu-okruzheniyu\_345.html](https://docs.usergate.com/trebovaniya-k-setevomu-okruzheniyu_345.html)  порты 9000-9100 используются для передачи информации об изменении конфигурации кластера (реплика настроек).

Соответственно если не включать на зоне Untrusted сервис Кластер (что вряд-ли понадобится), то вполне можно прокидывать порты из данного диапазона.&#x20;

11\) Если интерфейс, через который публикуется ресурс, находится в отдельном VRF, потребуется настроить Route leaking для DNAT (Port Forwarding) по инструкции из статьи [https://sd.usergate.com/articles/1820](https://sd.usergate.com/articles/1820)

# Пояснения

Опубликовать ресурсы можно как правилом DNAT так и порт-форвардингом, но если вам не нужно менять порты назначения, удобнее использовать правило DNAT.

Создание разрешающих правил МЭ для трафика DNAT, по умолчанию не нужно, но если у вас создано запрещающее правило МЭ, под которое может попасть прямой или обратный трафик за исключением правила "Default block", то вам нужно выше создать разрешающие правило для трафика DNAT.