Подмена IP при пробросе портов
-
Но ведь аналогичное второе правило у меня есть и на версии 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 сегмент, назначить обоим интерфейсам адреса из одной подсети и форвардить через него порты от одного хоста локалки другому. Честно говоря, тоже теряюсь в догадках…
-
Rubic, какая разница нужно для чего, имхо это к теме меньше всего относится. Есть факт что старая версия работает, новая нет.
Касательно сети. Тут разницы нет, факт что подмена не происходит. Пробывал с локальной сети (с хоста с адресом 192.168.252.200). Подмена все равно не верная, трафик приходит с 192.168.252.100, а нужно чтобы приходил с 192.168.252.105 -
У Вас 2 правило так же натит от имени WAN
-
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. Это поможет?
-
rubic, дорогой коллега, вместо критики я хотел бы услышить конструктивные предложения. Какие правила в таком случае и как поменять? Еще раз - не вижу ошибки в работе старой версии. Почему в новой WAN натит а LAN нет? Давайте уберу все правила NAT c WAN. Это поможет?
Попробуйте во 2 правиле поставить ограничение на DEST !ваша_сетка Это всё таки нат для интернета.
-
Не спасло…
-
В 1 правиле Nat address и Nat port обнулите
-
rubic, дорогой коллега, вместо критики я хотел бы услышить конструктивные предложения. Какие правила в таком случае и как поменять? Еще раз - не вижу ошибки в работе старой версии. Почему в новой WAN натит а LAN нет? Давайте уберу все правила NAT c WAN. Это поможет?
Когда два интерфейса смотрят в один ethernet сегмент, для исходящего из pfSense трафика используется только один из них. Это отражено в документации, но ссылку я на вскидку сейчас не найду. Какой именно? Как-то выбирает система. С точки зрения port forward выходной интерфейс в правилах, как вы знаете, явно не задашь. Его опять же выбирает система на основе таблицы маршрутизации. А поскольку в ней выход в LAN на первом этапе определен через WAN, то и летит все с него.
Вы лучше объясните задачу не на уровне вашей реализации, а в общих словах. В смысле зачем вам надо-то чтобы один хост ходил на другой через третий. Почему им нельзя говорить напрямую и т.д. -
Рисуйте схему со связями, адресами\сетями , интерфейсами, т.е. что куда "смотрит" и через что "входит\выходит".
Только внимательно сперва обдумайте все, чтобы не было "аааа…я вот тут еще адрес неправильно указал\забыл указать"
