Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Russian
    21 Posts 4 Posters 2.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • X Offline
      xl
      last edited by

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

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

      Capture.PNG
      Capture.PNG_thumb
      Capture2.PNG
      Capture2.PNG_thumb
      Capture3.PNG
      Capture3.PNG_thumb

      1 Reply Last reply Reply Quote 0
      • P Offline
        pigbrother
        last edited by

        Вот, что писал сооснователь 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.

        1 Reply Last reply Reply Quote 0
        • X Offline
          xl
          last edited by

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

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

          Capture.PNG
          Capture.PNG_thumb

          1 Reply Last reply Reply Quote 0
          • werterW Offline
            werter
            last edited by

            Доброе.

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

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

            1 Reply Last reply Reply Quote 0
            • X Offline
              xl
              last edited by

              Спасибо, но там дело не только в редиректе, там еще DLP и прочее.

              Возможно ли как-то создать запрос к разработчикам? Возможно, такое поведение это баг, вроде как ничего не мешает правилам работать на WAN, но они не работают.

              1 Reply Last reply Reply Quote 0
              • P Offline
                pigbrother
                last edited by

                вроде как ничего не мешает правилам работать на WAN, но они не работают.

                Когда поднят IPsec в 0.0.0.0/0, WAN-интерфейс перестает быть WAN. Реально он получается  подложкой для IPsec, который, собственно, и смотрит в мир. Поэтому правила на WAN не работают, пакеты приходят и уходят из\в IPsec минуя WAN.
                На IPsec правила не работают в силу специфики IPsec\его реализации в pfSense,тут моя недокомпетентность заканчивается.

                1 Reply Last reply Reply Quote 0
                • X Offline
                  xl
                  last edited by

                  Будет ли работать так? Если вручную отредактировать ipsec.conf для исключения одного хоста из туннеля?
                  virtual_private=%v4:10.10.10.0/24,%v4:!10.10.10.100/32

                  Сам по себе WAN работает, т.е. можно зайти в веб-консоль или в SSH. Не работает именно форвардинг.

                  1 Reply Last reply Reply Quote 0
                  • R Offline
                    rubic
                    last edited by

                    а "IPv4 Upstream gateway" в настройках WAN у вас заполнено?

                    1 Reply Last reply Reply Quote 0
                    • X Offline
                      xl
                      last edited by

                      Нет, там PPPoE, но на статике тоже самое, проверяли с другим провайдером.

                      1 Reply Last reply Reply Quote 0
                      • P Offline
                        pigbrother
                        last edited by

                        А по какому IP вы обращаетесь извне, когда поднят ipsec?
                        Знаете ли вы IP, через который выпускает вас  в интернет сервис который "защищает" траффик
                        Может это  серый IP, а сервис выпускает вас через NAT?
                        Может быть с его стороны вообще закрыты все попытки внешних подключений?

                        1 Reply Last reply Reply Quote 0
                        • werterW Offline
                          werter
                          last edited by

                          2 pigbrother
                          Как я понял, ТС хочет чтобы порты пробрасывались с его ВАН (?)

                          1 Reply Last reply Reply Quote 0
                          • P Offline
                            pigbrother
                            last edited by

                            @werter:

                            2 pigbrother
                            Как я понял, ТС хочет чтобы порты пробрасывались с его ВАН (?)

                            Или я чего-то не понимаю, но т.к
                            Сервис работает через ipsec, на машине подняли ipsec туннель до сервиса с remote 0.0.0.0/0, т.е. весь трафик пошел через него.
                            То pfSense может и слушает WAN, но ответы отправляет через ipsec, фактически ставший реальным WAN.

                            1 Reply Last reply Reply Quote 0
                            • X Offline
                              xl
                              last edited by

                              На WAN белый статический адрес, который получаем через PPPoE. В веб-консоль и SSH заходим через него (как я уже писал, в веб-консоль и SSH с поднятым туннелем пускает, не работает только форвардинг).
                              IP который дает сервис известен, даже делали проброс через него (правило на Ipsec на скриншоте выше + правило на стороне сервиса). Но это не вариант так как DNS привязан к WAN адресу, да и медленно.

                              Задача стоит сохранить форвардинг на WAN при поднятом туннеле :)

                              1 Reply Last reply Reply Quote 0
                              • werterW Offline
                                werter
                                last edited by

                                В веб-консоль и SSH заходим через него (как я уже писал, в веб-консоль и SSH с поднятым туннелем пускает, не работает только форвардинг).

                                Т.е. у вас есть форвардинг на ВАН для ssh и web-фейса ? И он извне работает ?

                                1. Что шлюзом у вас на той лок. машине в сети, на к-ую делается проброс ? Должен быть ip пф . Проверьте этот момент.
                                2. Откл. все fw, антивирусы на той лок. машине в сети, на к-ую делается проброс. И встроенный в Вин (если там эта ОС) так же. Если же на машине *nix - просмотреть настройки fw или настройки ПО, к-ое на ней крутится.

                                1 Reply Last reply Reply Quote 0
                                • X Offline
                                  xl
                                  last edited by

                                  Веб-консоль и SSH работают без форварда (оно же на самом pfsense, форвард не нужен), просто разрешающее правило на WAN.
                                  Проброс c WAN на машину в LAN работает без проблем когда туннель выключен. Стоит включить туннель и проброс работать перестает.

                                  1 Reply Last reply Reply Quote 0
                                  • werterW Offline
                                    werter
                                    last edited by

                                    ВАНом становится др. конец ipsec-туннеля. На нем проброс и пробовать делать. Или сменить хостера и тип впн на openvpn.

                                    P.s. Отпишитесь в баг-трекер. Этим поможете целому сообществу.

                                    1 Reply Last reply Reply Quote 0
                                    • P Offline
                                      pigbrother
                                      last edited by

                                      ВАНом становится др. конец ipsec-туннеля

                                      Согласен.
                                      Несколько постов назад я пытался это донести до ТС.

                                      1 Reply Last reply Reply Quote 0
                                      • R Offline
                                        rubic
                                        last edited by

                                        В pf есть вещи посильнее WANа (WAN - это вообще условность), а именно Policy Based Routing (PBR). Настройка "IPv4 Upstream gateway" в предпочитаемом WAN, по идее, перекрывает системные маршруты, ибо добавляет в правила "replay-to", что полезно при port forward.
                                        Автор, что выдает pfctl -sr | grep reply-to?

                                        1 Reply Last reply Reply Quote 0
                                        • X Offline
                                          xl
                                          last edited by

                                          То, что ipsec заменят WAN я понял сразу, спасибо (это не грубость, может я что-то не так написал в первом посте :) )
                                          Весь вопрос был о том, как победить такое поведение, попробую написать в баг-треккер.

                                          Настройка "IPv4 Upstream gateway" не доступна, если адрес получается через PPPoE.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.