Не работает port forward когда поднят IPSec туннель



  • Всем привет.
    Такая ситуация:

    Есть машина с обычными правилами редиректа WAN - LAN, проброс фтп, хттп в локалку.
    Некоторое время назад фирма купила сервис который "защищает" траффик. Сервис работает через ipsec, на машине подняли ipsec туннель до сервиса с remote 0.0.0.0/0, т.е. весь трафик пошел через него.
    Когда туннель поднят проброс портов не работает. В стейтах вижу: CLOSED:SYN_SENT. Т.е. трафик приходит через WAN и пытается уйти через ipsec как я понимаю.
    Пробовал в правилах файрволла конкретно указывать шлюз для адресов из локалки куда идет проброс. При этом на хосте (в локалке) совсем пропадает интернет, трейс показывает * * * на всех хопах.
    Пробовал сделать обратный NAT для адресов из локалки (как для тех случаев когда у хоста другой шлюз), не помогло.
    Если туннель выключить, все начинает работать как обычно.

    Кто сталкивался с таким? Что можно сделать?



  • А на каком интерфейсе вы делаете port forward?
    ipsec ведь невозможно  назначить интерфейс?



  • Форвард на WAN, хочется чтобы он там и работал в обход туннеля. Можно создать правила форварда на Ipsec, но это ничего не дает, что вполне логично.

    На 3 скриншоте видно что для LAN не указан шлюз конкретно, если там указать шлюз WAN при поднятом туннеле, в LAN полностью пропадает внешний интернет.








  • Вот, что писал сооснователь pfSense про похожую ситуацию:
    That might be doable with a port forward on the IPsec interface. I can't recall ever needing to do something like that, and NAT and IPsec have weird interactions in some instances by the nature of how things work in the underlying system, but I think that circumstance would work with a port forward. That's the way you'd redirect traffic in that manner. It definitely works with OpenVPN. Probably does with IPsec also.



  • Да, с OpenVPN все работает, а вот strongswan какой-то агрессивный :)
    Посмотрел tcpdump и Wireshark, пакеты совсем не доходят до хоста в LAN при поднятом туннеле.

    В стейтах оно выглядит как на скриншоте.




  • Доброе.

    Некоторое время назад фирма купила сервис который "защищает" траффик. Сервис работает через ipsec

    Если все же не выйдет с ipsec, то стоит попробовать купить недорогой vps (https://hosting.cafe/) + прикрутить это https://pritunl.com/, https://github.com/pritunl/pritunl
    Разворачивается за минуты , имеет веб-фейс.



  • Спасибо, но там дело не только в редиректе, там еще 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
    Как я понял, ТС хочет чтобы порты пробрасывались с его ВАН (?)



  • @werter:

    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.


Log in to reply