Не перенаправляются пакеты при обращении

[IT-ALEX]

Здравствуйте, коллеги.

Конфигурация pfSense.
Стоит в качестве farewell и пропускает из интернета во внутреннею сеть только один порт RDP 3389 для подключения к терминальному серверу.

Правило перенаправления порта и правила farewell совпадают:
Интерфейс WAN
Протокол TCP
Адрес Источника any
Порты Источника any
Адрес Назначения any
Порты Назачения 3389
NAT IP 192.168.0.1
Порты NAT 3389
Описание RDP
Действия Разрешть

Когда обращаюсь к pfSense по DNS имени test.mydomen.ru из интернета по средствам удаленного рабочего стола мне видеться окно авторизации. Я думаю, что идет авторизация на сам pfSeanse, так как логах безопасности сервера терминалов нет информации о попытки авторизоваться на сервере.

А, когда обращаюсь к pfSense по IP адресу из интернета по средствам удаленного рабочего стола попадаю на сервер.

Что я не докрутил подскажите пожалуйста.

[ToXaNSK]

test.mydomen.ru отвечает по тому же IP?
А почему "Адрес Назначения  any"?

Я правильно понял, вы создаете правило в NAT? Т.к. правило для Firewall создается само.

[IT-ALEX]

test.mydomen.ru отвечает по тому же IP? Да.
А почему "Адрес Назначения  any"? Если я ставлю внутренний IP (192.168.0.1) куда нужно пересылать то я не могу попасть.

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

[werter]

Доброе.
Адрес назначения- Wan address

[pigbrother]

@werter:

Доброе.
Адрес назначения- Wan address

Вот и начались радости русификации.
Исторически Dest. Address\Адрес назначения не указываю. Все работает и без него.

Подскажите пожалуйста, где смотреть логи всех подключений которые обращаются на WAN интерфейс.
Логи можно видеть:
1. Для явно созданных правил, включив в правиле  галку "Log packets that are handled by this rule"
2. Включив в Status-System Logs- Settings галку "Log packets matched from the default block rules in the ruleset"

[ToXaNSK]

Вот так вот работает:

[pigbrother]

Вот так вот работает

И?

[ToXaNSK]

@pigbrother:

Вот так вот работает

И?

И!? Это мне!?

[werter]

Доброе.
@pigbrother:

Вот и начались радости русификации.
Исторически Dest. Address\Адрес назначения не указываю. Все работает и без него.

Еще с версии 1.2.3 исторически указываю адрес назначения. Проблем не было.

[pigbrother]

@ToXaNSK:

@pigbrother:

Вот так вот работает

И?

И!? Это мне!?

Явно не вам, не посмотрел на автора поста.
Dest. address вы, как вижу, тоже не используете.

Еще с версии 1.2.3 исторически указываю адрес назначения. Проблем не было.

Нигде не нашел внятного объяснения, зачем Dest. address все же нужен. Понимаю, что поле для его ввода предусмотрено не зря.
Судя по
https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense
Destination: Specifies the original destination IP address of the traffic, as seen before being translated, and will usually be
WAN address.
Это дает возможность подменить интерфейс-источник пакета до трансляции.

[ToXaNSK]

Я правильно понял. Dest. Address в NAT. А указывать что не нарваться на подмену?

[pigbrother]

@ToXaNSK:

Я правильно понял. Dest. Address в NAT. А указывать что не нарваться на подмену?

Думаю - дело не в безопасности. Вероятно,  это нужно для организации более сложных вариантов dst-nat, чем простой port forward.

[IT-ALEX]

Не работает!
Еще я не вижу обращение к pfsense из интернета в логах нет записей.

[pigbrother]

Стандартный чеклист:

1.На вашем SRV1 брандмауэр вылючен\настроен?
2. IP на WAN - "белый"?
3. является ли pfSense шлюзом по умолчанию для SRV1?

P.S
На скриншоте видно, что данные бегают - открыто 2 стейта и передано 116 кб.
Франзусско-нижегородский  Англо-русский интерфейс вводит в ступор.

[werter]

Доброе.
Там, где выделено - Wan address. Плюс для ICMP выбрать только Echo reply.