Подмена IP при пробросе портов
-
Вы хотите пробрасывать все обращения к 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, то и летит все с него.
Вы лучше объясните задачу не на уровне вашей реализации, а в общих словах. В смысле зачем вам надо-то чтобы один хост ходил на другой через третий. Почему им нельзя говорить напрямую и т.д. -
Рисуйте схему со связями, адресами\сетями , интерфейсами, т.е. что куда "смотрит" и через что "входит\выходит".
Только внимательно сперва обдумайте все, чтобы не было "аааа…я вот тут еще адрес неправильно указал\забыл указать"
-
dvserg обнулил NAT порт, а как обнулить NAT address? pfsense там автоматом поставил LAN address…
rubic о чем вы? Какие выборы интерфейсов?? Я с хоста четко обращаюсь на адресс wan на 443 порт, дальше должен отрабатывать pfsense и согласно правилам пробрасывать трафик на дестинайшен хост, если бы LAN натил нормально, то на дистенайшен должен приходит трафик внутри с адресом с интерфейса LAN, а не соурс хоста. Этого не происходит, при чем тут ваши рассуждения?
Честно, даже не хочу спорить. -
dvserg обнулил NAT порт, а как обнулить NAT address? pfsense там автоматом поставил LAN address…
rubic о чем вы? Какие выборы интерфейсов?? Я с хоста четко обращаюсь на адресс wan на 443 порт, дальше должен отрабатывать pfsense и согласно правилам пробрасывать трафик на дестинайшен хост, если бы LAN натил нормально, то на дистенайшен должен приходит трафик внутри с адресом с интерфейса LAN, а не соурс хоста. Этого не происходит, при чем тут ваши рассуждения?
Честно, даже не хочу спорить.При том, что трафик через LAN вообще не идет, какое уж там "натил". Он пришел на WAN, порт форвардом поменял destination, а потом через WAN же к целевому хосту и вылетел, пройдя WAN outbound NAT. Это я вам и пытаюсь объяснить, не тупите. Можете outbound NAT на LAN вообще удалить, ничего не измениться.
