Подмена IP при пробросе портов
-
доброго времени суток!
помогите пожалуйста с таким вопросом:
у меня pfSense разделяет две сети (192.168.1.0 и 172.16.1.0). В первую сеть 192.168.1.0 смотрит интерфейс 192.168.1.1, на котором настроен PortForwards порта 8080 на сервер 172.16.1.2 из второй сети, в неё смотрит интерфейс 172.16.1.1. При обращении клиента (допустим 192.168.1.2) к 192.168.1.1:8080 на сервере 172.16.1.2 я вижу обращение с адреса 192.168.1.2.
Вопрос: в какие настройки лезть и что менять, чтобы pfSense подменял в исходящих пакетах 192.168.1.2 на свой внешний 172.16.1.1 и соответственно все общение со второй сетью шло именно от этого ip?
надеюсь более менее понятно обрисовал проблему :)версия pfSense-2.1-RELEASE
спасибо
-
Поднять NAT
-
как его поднять?
Я полагал что NAT по умолчанию включен, раз pfsense это "программный маршрутизатор"з.ы. Outbound NAT чтоле колупать? ???
-
@DLI:
как его поднять?
Я полагал что NAT по умолчанию включен, раз pfsense это "программный маршрутизатор"Ну кто-же его знает какие настройки у Вас там уже есть?
з.ы. Outbound NAT чтоле колупать? ???
Да, NAT подменяет исходящий адрес на адрес своего интерфейса.
Включите ручной NAT, чтобы быть уверенным что там за правила создаются. -
всё, разобрался. Благодарю!
-
DLI, как сделал? Таже проблема… Настроил NAT, ничего не меняется. Почитал-погуглил, настроил Outbound - ничего не изменилось, не работает. Причем на старой версии 1.2 с такими же правилами все работает. Что нет так? Напиши подробнее пожалуйста, как победил, очень нужно...
Заранее спасибо.... -
Может подскажет модератор…
Вот скрины правил которые сделаны на версии 2.х
-
Те же правила, но работающие на старой версии 1.х
Что не так?… Просто уже крик души...
-
Скорее всего у Вас на 1.2 работало 2 правило вместо первого.
Для правила OUTBOUND LAN вы должны указать DEST адрес = WAN и DEST порт = 443
-
Но ведь аналогичное второе правило у меня есть и на версии 2.Х… Почему оно не работает?
Ееще раз - можно пояснить где у меня ошибка на Outbound? Как может быть Destination WAN если обращение идет в внутренниму (LAN) интерфейсу? Почему порт 443 или с сервера пойдет ответ по 3389 порту?
Ведь суть правила как раз и заключается что на WAN приходит запрос на 443 порт, pfsense его перебрасывает в LAN network на 3389 порт, соовтественно ответ с сервера на LAN интерфейс должен пойти именно по 3389 порту.
Разве нет? -
Но ведь аналогичное второе правило у меня есть и на версии 2.Х… Почему оно не работает?
Ееще раз - можно пояснить где у меня ошибка на Outbound? Как может быть Destination WAN если обращение идет в внутренниму (LAN) интерфейсу? Почему порт 443 или с сервера пойдет ответ по 3389 порту?
Ведь суть правила как раз и заключается что на WAN приходит запрос на 443 порт, pfsense его перебрасывает в LAN network на 3389 порт, соовтественно ответ с сервера на LAN интерфейс должен пойти именно по 3389 порту.
Разве нет?Ещё раз чётко сформулируйте Вашу проблему.
Что и откуда не работает и как должно быть. -
Суть проблемы - не работает подмена IP (иначе говоря маскарадинг - IP masquerade).
Есть плоская сеть. Нужно пробрасывать запросы на разные порты (знаю что нот бай дезайн и все такое прочее).
Есть pfsense. На нем есть WAN интерфейс с адресом 192.168.252.100 (а так же шлюзом и маской 22). Есть LAN интерфейс с адресом 192.168.252.105. Есть хост с адресом 192.168.252.110. Есть Хост с адресом 192.168.252.1.Есть правило что все запросы из WAN на 443 порт перебрасывать на хост 192.168.252.110 на порт 3389. (скрины я выкладывал).
Есть Outbond правила. На хосте 192.168.252.110 стоит Wireshark.
В случае использования pfsense 2.x он показывает что все запросы на подключение к хосту 192.168.252.110 приходят с 192.168.252.1. Если использовать pfsense 1.x то masquerade отрабатывает и Wireshark показывает на хосту 192.168.252.110 что все запросы приходят с 192.168.252.105
Соотвественно непонятно почему одни и теже правила на разных версиях не работают.
Надеюсь я понятно изложил суть проблемы… -
Вы хотите пробрасывать все обращения к WAN интерфейсу из локальной сети.
Главная и основная проблема в том, что локальный сервис видит напрямую хост источник и отвечает ему мимо pfSense.Для этого кроме маскарадинга (проброса) Dest адреса/порта нужно изменить NATом Source адреса на адреса WAN интерфейса. Поэтому для правил 2.1 сделайте по моим рекомендациям выше.
-
Видимо я не правильно изложил, вы меня не поняли. На хосте к которому приходят запросы - запросы приходят на 3389 порт, но адрес соурс не LAN pfsense, а адрес хоста с которого иницирован запрос на 443 порт. Т.е. не происходит подмена на входящих пакетах (т.е. то что прошло через pfsense не подменило соурс адрес). При чем тут то что хост с которого идет запрос так же доступен? Я сейчас не об обратных пакетах, а о тех что приходят.
-
Видимо я не правильно изложил, вы меня не поняли. На хосте к которому приходят запросы - запросы приходят на 3389 порт, но адрес соурс не LAN pfsense, а адрес хоста с которого иницирован запрос на 443 порт. Т.е. не происходит подмена на входящих пакетах (т.е. то что прошло через pfsense не подменило соурс адрес). При чем тут то что хост с которого идет запрос так же доступен? Я сейчас не об обратных пакетах, а о тех что приходят.
Так Host_Local -> WAN[443] -> ServerLocal[3389] ?
Здесь
Для правила OUTBOUND LAN вы должны указать DEST адрес = WAN и DEST порт = 443 -
Добавил правило о котормо вы говорили. Ситуация не изменилась.
-
Посмотрите в таблице States состояния по фильтру на указанный IP
-
Только одно событие попадает под правило по работе с 443 и 3389 портом. Запрос делал в этот раз не с 192.168.252.1 а с маршрутизируемой соседней сети (10.71.х.х).
На pfsense 1.x из этой сети с моими правилами все работает, на 2.х нет…
-
Вторую страницу разбираем про правила NAT на LAN и тут вдруг из другой сетки… :-\
-
Причем на старой версии 1.2 с такими же правилами все работает. Что нет так?
Оригинальный pf.c постоянно совершенствуется разработчиками. Видимо, они не докумекали зачем кому-то может понадобиться воткнуть pfSense WAN-ом и LAN-ом в один Ethernet сегмент, назначить обоим интерфейсам адреса из одной подсети и форвардить через него порты от одного хоста локалки другому. Честно говоря, тоже теряюсь в догадках…