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

      Будет ли работать так? Если вручную отредактировать 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.