Подмена 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 порту.
    Разве нет?



  • @Feral:

    Но ведь аналогичное второе правило у меня есть и на версии 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 не подменило соурс адрес). При чем тут то что хост с которого идет запрос так же доступен? Я сейчас не об обратных пакетах, а о тех что приходят.



  • @Feral:

    Видимо я не правильно изложил, вы меня не поняли. На хосте к которому приходят запросы - запросы приходят на 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 и тут вдруг из другой сетки…  :-\



  • @Feral:

    Причем на старой версии 1.2 с такими же правилами все работает. Что нет так?

    Оригинальный pf.c постоянно совершенствуется разработчиками. Видимо, они не докумекали зачем кому-то может понадобиться воткнуть pfSense WAN-ом и LAN-ом в один Ethernet сегмент, назначить обоим интерфейсам адреса из одной подсети и форвардить через него порты от одного хоста локалки другому. Честно говоря, тоже теряюсь в догадках…



  • Rubic, какая разница нужно для чего, имхо это к теме меньше всего относится. Есть факт что старая версия работает, новая нет.
    Касательно сети. Тут разницы нет, факт что подмена не происходит. Пробывал с локальной сети (с хоста с адресом 192.168.252.200). Подмена все равно не верная, трафик приходит с 192.168.252.100, а нужно чтобы приходил с 192.168.252.105



  • У Вас 2 правило так же натит от имени WAN



  • @Feral:

    Rubic, какая разница нужно для чего, имхо это к теме меньше всего относится. Есть факт что старая версия работает, новая нет.
    Касательно сети. Тут разницы нет, факт что подмена не происходит. Пробывал с локальной сети (с хоста с адресом 192.168.252.200). Подмена все равно не верная, трафик приходит с 192.168.252.100, а нужно чтобы приходил с 192.168.252.105

    Ну и какой вывод? Пакеты на целевой хост летят с WAN pfSense, потому что по таблице маршрутизации у вас WAN от LAN ничем не отличаются (типа, так задумано). Оба ведут в одну и ту же сеть и имеют outbound NAT на адрес интерфейса. Откуда pfSense знать, что вы пробрасываете с WAN на LAN? Может с WAN на WAN? Ведь все эти названия - лишь условность, интерфейсы абсолютно равноправны.
    Так что с точки зрения теории все ок, так и должно быть. Если посмотрите таблицу маршрутизации, сами все увидите.
    Если что-то по ошибке работало в старой версии, это еще не значит, что ошибку не надо исправлять только из-за того, что кто-то ее использовал, организовав сущий замес и головоломками))



  • Ок. Как мне сделать чтобы натило только с LAN и на дистинайшен хост приходили пакеты с сорсом 192.168.252.105?



  • rubic, дорогой коллега, вместо критики я хотел бы услышить конструктивные предложения. Какие правила в таком случае и как поменять? Еще раз - не вижу ошибки в работе старой версии. Почему в новой WAN натит а LAN нет? Давайте уберу все правила NAT c WAN. Это поможет?



  • @Feral:

    rubic, дорогой коллега, вместо критики я хотел бы услышить конструктивные предложения. Какие правила в таком случае и как поменять? Еще раз - не вижу ошибки в работе старой версии. Почему в новой WAN натит а LAN нет? Давайте уберу все правила NAT c WAN. Это поможет?

    Попробуйте во 2 правиле поставить ограничение на DEST !ваша_сетка Это всё таки нат для интернета.



  • Не спасло…




  • В 1 правиле Nat address и Nat port обнулите



  • @Feral:

    rubic, дорогой коллега, вместо критики я хотел бы услышить конструктивные предложения. Какие правила в таком случае и как поменять? Еще раз - не вижу ошибки в работе старой версии. Почему в новой WAN натит а LAN нет? Давайте уберу все правила NAT c WAN. Это поможет?

    Когда два интерфейса смотрят в один ethernet сегмент, для исходящего из pfSense трафика используется только один из них. Это отражено в документации, но ссылку я на вскидку сейчас не найду. Какой именно? Как-то выбирает система. С точки зрения port forward выходной интерфейс в правилах, как вы знаете, явно не задашь. Его опять же выбирает система на основе таблицы маршрутизации. А поскольку в ней выход в LAN на первом этапе определен через WAN, то и летит все с него.
    Вы лучше объясните задачу не на уровне вашей реализации, а в общих словах. В смысле зачем вам надо-то чтобы один хост ходил на другой через третий. Почему им нельзя говорить напрямую и т.д.



  • Рисуйте схему со связями, адресами\сетями , интерфейсами, т.е. что куда "смотрит" и через что "входит\выходит".

    Только внимательно сперва обдумайте все, чтобы не было "аааа…я вот тут еще адрес неправильно указал\забыл указать"



  • dvserg обнулил NAT порт, а как обнулить NAT address? pfsense там автоматом поставил LAN address…

    rubic о чем вы? Какие выборы интерфейсов?? Я с хоста четко обращаюсь на адресс wan на 443 порт, дальше должен отрабатывать pfsense и согласно правилам пробрасывать трафик на дестинайшен хост, если бы LAN натил нормально, то на дистенайшен должен приходит трафик внутри с адресом с интерфейса LAN, а не соурс хоста. Этого не происходит, при чем тут ваши рассуждения?
    Честно, даже не хочу спорить.



  • @Feral:

    dvserg обнулил NAT порт, а как обнулить NAT address? pfsense там автоматом поставил LAN address…

    rubic о чем вы? Какие выборы интерфейсов?? Я с хоста четко обращаюсь на адресс wan на 443 порт, дальше должен отрабатывать pfsense и согласно правилам пробрасывать трафик на дестинайшен хост, если бы LAN натил нормально, то на дистенайшен должен приходит трафик внутри с адресом с интерфейса LAN, а не соурс хоста. Этого не происходит, при чем тут ваши рассуждения?
    Честно, даже не хочу спорить.

    При том, что трафик через LAN вообще не идет, какое уж там "натил". Он пришел на WAN, порт форвардом поменял destination, а потом  через WAN же к целевому хосту и вылетел, пройдя WAN outbound NAT. Это я вам и пытаюсь объяснить, не тупите. Можете outbound NAT на LAN вообще удалить, ничего не измениться.



  • werter, на одного вас надежда… Хоть какой-то конструктив...
    Только не спрашивай зачем мне все это нужно, повторюсь, знаю что нот бай дизайн, знаю что тупо и тп. Просто мне это нужно...
    Вот картинка. В иделае ситуация такая, мне нужно на хост Х.252.103 чтобы из сети 10.х приходил запрос на 3389 и на 443 порт форвадились запросы тоже на 3389 на Х.252.103. Картинка прояснит...
    Так вот, на Х.252.103 все пакеты при запросе на 443 порт приходят, но соурс не .252.105! может быть соурс WAN адреса если из сети 252 обращаюсь, 10.ххх если из сети 10...
    Но на старой версии 1.2.3 все работает как мне нужно... на 2.1 нет....



  • Он пришел на WAN, порт форвардом поменял destination, а потом  через WAN же к целевому хосту и вылетел, пройдя WAN outbound NAT

    А у меня давно вопрос имеется как раз по движению траффика: есть ли у кого подробная схема движения траффика в pfsense, как к примеру для микротика:




  • @aleksvolgin:

    А у меня давно вопрос имеется как раз по движению траффика: есть ли у кого подробная схема движения траффика в pfsense, как к примеру для микротика




  • Почему он снова через WAN вылетает? Как ему указать идти на LAN интерфейс?
    Поменял правило, теперь с любой сети идешь и соурс меняется на WAN. Почему на 1.2.3 он менял на LAN соурс и поворачивал трафик на LAN? А новой, продвинутой версии перестал??




  • 2 rubic
    Спасибо.



  • @Feral:

    Почему он снова через WAN вылетает? Как ему указать идти на LAN интерфейс?

    Почему я вам выше все объяснил, читайте. А по сути проблемы попробуйте отключить LAN pfSense от сети, пусть в ней только WAN будет, на нем все и настройте, адрес ему дайте 105, если это принципиально.
    ЗЫ c 10.x.x.x не подменяет источник потому, что на WAN outbound NAT нет правила для этой сети.
    UPD: LANу дайте адрес и маску из любой левой подсети. В принципе можно и не отключать его из свитча



  • rubic, извини если был груб. Просто не понимаю почему старая версия работает, новая нет… (вот серьезно, в чем причина и логика?) А какое нужно прописать правило чтобы с сетью 10.х заработало?
    ЗЫ А как pfsense будет работать на одном интерфейсе?



  • В NAT Outbound:
    WAN 10.x.x.x * * * * *
    То же, что и для LAN прописано, только Source 10.x.x.x
    Так же как и сейчас будет работать, вы просто привыкли думать, что трафик должен влететь через один интерфейс, а вылететь через именно другой. Но это не так, входной интерфейс может быть тем же, что и выходной, при этом пакет проходит все этапы на картинке выше. Выходной интерфейс определяется на этапе routing и может быть тем же, как по вашему иначе локальные сервисы, тот же GUI бы работали? Ведь вы шлете на LAN запрос и получаете с него же веб-морду pfSense.