Не работает port forward когда поднят IPSec туннель
-
Спасибо, но там дело не только в редиректе, там еще DLP и прочее.
Возможно ли как-то создать запрос к разработчикам? Возможно, такое поведение это баг, вроде как ничего не мешает правилам работать на WAN, но они не работают.
-
вроде как ничего не мешает правилам работать на WAN, но они не работают.
Когда поднят IPsec в 0.0.0.0/0, WAN-интерфейс перестает быть WAN. Реально он получается подложкой для IPsec, который, собственно, и смотрит в мир. Поэтому правила на WAN не работают, пакеты приходят и уходят из\в IPsec минуя WAN.
На IPsec правила не работают в силу специфики IPsec\его реализации в pfSense,тут моя недокомпетентность заканчивается. -
Будет ли работать так? Если вручную отредактировать ipsec.conf для исключения одного хоста из туннеля?
virtual_private=%v4:10.10.10.0/24,%v4:!10.10.10.100/32Сам по себе WAN работает, т.е. можно зайти в веб-консоль или в SSH. Не работает именно форвардинг.
-
а "IPv4 Upstream gateway" в настройках WAN у вас заполнено?
-
Нет, там PPPoE, но на статике тоже самое, проверяли с другим провайдером.
-
А по какому IP вы обращаетесь извне, когда поднят ipsec?
Знаете ли вы IP, через который выпускает вас в интернет сервис который "защищает" траффик
Может это серый IP, а сервис выпускает вас через NAT?
Может быть с его стороны вообще закрыты все попытки внешних подключений? -
2 pigbrother
Как я понял, ТС хочет чтобы порты пробрасывались с его ВАН (?) -
2 pigbrother
Как я понял, ТС хочет чтобы порты пробрасывались с его ВАН (?)Или я чего-то не понимаю, но т.к
Сервис работает через ipsec, на машине подняли ipsec туннель до сервиса с remote 0.0.0.0/0, т.е. весь трафик пошел через него.
То pfSense может и слушает WAN, но ответы отправляет через ipsec, фактически ставший реальным WAN. -
На WAN белый статический адрес, который получаем через PPPoE. В веб-консоль и SSH заходим через него (как я уже писал, в веб-консоль и SSH с поднятым туннелем пускает, не работает только форвардинг).
IP который дает сервис известен, даже делали проброс через него (правило на Ipsec на скриншоте выше + правило на стороне сервиса). Но это не вариант так как DNS привязан к WAN адресу, да и медленно.Задача стоит сохранить форвардинг на WAN при поднятом туннеле :)
-
В веб-консоль и SSH заходим через него (как я уже писал, в веб-консоль и SSH с поднятым туннелем пускает, не работает только форвардинг).
Т.е. у вас есть форвардинг на ВАН для ssh и web-фейса ? И он извне работает ?
1. Что шлюзом у вас на той лок. машине в сети, на к-ую делается проброс ? Должен быть ip пф . Проверьте этот момент.
2. Откл. все fw, антивирусы на той лок. машине в сети, на к-ую делается проброс. И встроенный в Вин (если там эта ОС) так же. Если же на машине *nix - просмотреть настройки fw или настройки ПО, к-ое на ней крутится. -
Веб-консоль и SSH работают без форварда (оно же на самом pfsense, форвард не нужен), просто разрешающее правило на WAN.
Проброс c WAN на машину в LAN работает без проблем когда туннель выключен. Стоит включить туннель и проброс работать перестает. -
ВАНом становится др. конец ipsec-туннеля. На нем проброс и пробовать делать. Или сменить хостера и тип впн на openvpn.
P.s. Отпишитесь в баг-трекер. Этим поможете целому сообществу.
-
ВАНом становится др. конец ipsec-туннеля
Согласен.
Несколько постов назад я пытался это донести до ТС. -
В pf есть вещи посильнее WANа (WAN - это вообще условность), а именно Policy Based Routing (PBR). Настройка "IPv4 Upstream gateway" в предпочитаемом WAN, по идее, перекрывает системные маршруты, ибо добавляет в правила "replay-to", что полезно при port forward.
Автор, что выдает pfctl -sr | grep reply-to? -
То, что ipsec заменят WAN я понял сразу, спасибо (это не грубость, может я что-то не так написал в первом посте :) )
Весь вопрос был о том, как победить такое поведение, попробую написать в баг-треккер.Настройка "IPv4 Upstream gateway" не доступна, если адрес получается через PPPoE.
