Симптомы

Не работает NAT или DNAT с другим IP адресом, не принадлежащим интерфейсу NGFW.

Решение

Имеется 2 возможных сценария:

1) На вышестоящем оборудовании указан маршрут в сторону данного IP через шлюз NGFW, которым является реальный адрес на интерфейсе. В случае, если бы маршрута не было, соседний роутер отправил бы ARP запрос, на который UG бы не ответил, так как NGFW не отвечает на ARP-запросы для адресов, не принадлежавших его интерфейсам.

2) На вышестоящем оборудовании не указан маршрут в сторону данного IP через шлюз NGFW.
В таком случае данный IP адрес должен быть назначен на интерфейсе явно как secondary IP, или в качестве VIP адреса в кластере, так как NGFW не отвечает на ARP-запросы для адресов, не принадлежавших его интерфейсам.

Причина

В поле SNAT можно указать любой адрес, даже не назначенный на интерфейсе, трансляция будет происходить, но проблема будет в отправке ответных пакетов, так как по умолчанию NGFW не будет отвечать на ARP запрос на этот адрес (если он не назначен на интерфейсе). Можно это обойти, сделав статическую запись ARP на вышестоящем оборудовании, указать что данный IP принадлежит MAC адресу NGFW или включить на самом NGFW опцию proxyARP на нужном интерфейсе, тогда NGFW будет отвечать своим MAC на все ARP запросы, но это может привести к проблемам на сети. Не рекомендуется без чёткого понимания включать данную опцию. Самый простой и надежный вариант это назначить Secondary IP на интерфейсе NGFW.

Симптомы

Имеется 2 правила DNAT, в которых все условия одинаковые, кроме адресов назначения на внешних интерфейсах:

При этом на первом правиле включён SNAT, а на втором отключён.

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

Решение

Это является результатом особенности работы SNAT в DNAT. При включении галки SNAT в правиле DNAT для адреса назначения 172.25.42.172, внутрь системы спускается условие, в котором указано, что для адреса назначения 192.168.10.254 для соединений с состоянием DNAT по порту 80 необходимо выполнять SNAT, но при этом адрес назначения не учитывается. По этому поводу уже заведена задача SUM-13010.

Симптомы

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

Решение

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

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

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

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

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

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

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

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

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

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

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

7) Трафик не проходит через правило DNAT из-за разных драйверов на интерфейсах, через которые он проходит к публикуемому серверу.

Отключить модуль Fastpath согласно данной статье https://sd.usergate.com/articles/14 и затем проверить работу правила.

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

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

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

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

Проверить отсутствие указанного в правиле DNAT порта (либо диапазона портов) в таблице - https://docs.usergate.com/trebovaniya-k-setevomu-okruzheniyu_1349.html

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

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

Пояснения

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

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

Симптомы

Возникла проблема при публикации FTP сервера через Port-forwarding или DNAT.

Решение

Согласно данной статьи документации - https://docs.usergate.com/publikaciya-ftp-servera_33.html

В версиях выше 5-й, для корректной работы, необходимо активировать модуль ftp-alg через консоль CLI:

В 6 версии:

device config -set module_ftp_alg_enabled true

В 7 версии:

configure
set settings device ftp-alg on

Также стоить обратить внимание, для некоторых случаев публикации FTP для подмены в пакетах PAYLOAD (вставляя вместо реального адреса сервера адрес, через который он опубликован) потребуется включить на сервисном порту Application level gateway:

Для более подробного описания данного функционала в документации создана задача DOC-344.
Начина с версии 7.2.0 модули Application level gateway включены по умолчанию.

Симптомы

Отсутствует доступ из локальной сети к внешнему ресурсу опубликованному через этот же NGFW.
Необходимо настроить доступ к опубликованным через DNAT сервисам изнутри сети (Hairpin NAT)

Решение

Для реализации данной задачи вам необходимо настроить правило Hairpin NAT.
В правиле с типом DNAT во вкладке Адрес назначения укажите IP внешнего интерфейса, во вкладке Зона источника отметьте зону внутреннего интерфейса, а во вкладке DNAT укажите внутренний адрес сервера. Пример:

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