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