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

    Доступ к удаленной VPN через WAN pfSense (port forwarding)

    Scheduled Pinned Locked Moved Russian
    28 Posts 5 Posters 3.9k 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.
    • M
      Max69 @werter
      last edited by Max69

      @werter Не знаю какой гемор, винда обновляется автоматом ... хочешь ставь все обновления, хочешь мажорные ...
      никакого гемора не было до обновления пф до 2.4.4

      werterW 1 Reply Last reply Reply Quote 0
      • M
        Max69 @werter
        last edited by Max69

        @werter А есть на других виртуальных платформах аналогичная возможность создать виртуальный шлюз на базе пф для виртуальной локальной сети. Если вы настолько против Hyper-V подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

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

          @Max69 said in Доступ к удаленной VPN через WAN pfSense (port forwarding):

          Не знаю какой гемор, винда обновляется автоматом

          Попробуйте обновить Hyper-v 2012 до 2019 )
          И да. Гипер-в бывает разный - отдельный и КАК РОЛЬ сервера. У вас какой?

          Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

          У PVE есть встроенный firewall c GUI. И без ВМ все можно гибко настроить. Мало того, этим же fw можно запретить\разрешить доступ к опред. портам\протоколам на самих VM. Для этого в настройках ВМ на сетевом интерфейсе есть галка Firewall.
          1.png
          2.png
          3.png

          Что такое PVE (и не только) forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5

          M 1 Reply Last reply Reply Quote 0
          • M
            Max69 @werter
            last edited by

            @werter
            Клево, как нибудь обязательно испытаю это удовольствие .

            Однако возвращаясь к вопросу, имею необходимость перенаправить порт с публичного IP через VPN туннель на локальную машину.
            На клиенте сделал проброс: 10.0.8.2:8090->192.168.1.18090
            На сервере делаю test port: 10.0.8.2 8090 Port test to host: 10.0.8.2 Port: 8090 successful. Т.е. сервер в интернете видит через VPN открытый порт на 192.168.1.1
            Делаю на сервере проброс
            Public IP:8090->10.0.8.2:8090, однако чрез Public IP соединения с веб-сервером нет. Что упускаю ?

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

              Зачем на клиенте проброс?

              Схему с адресацией в студию.

              M 1 Reply Last reply Reply Quote 0
              • M
                Max69 @werter
                last edited by Max69

                @werter
                Дано:
                <Интернет> pf Сервер (x.x.x.x) <vpn tun10.0.8.x> pf Клиент <lan> Веб сервер(y.y.y.y)
                Надо:
                Доступ из Интернет к y.y.y.y:81 через x.x.x.x:81

                На клиенте проброс 10.0.8.2:81->y.y.y.y:81 работает
                На сервере проброс х.х.х.x:81->10.0.8.2:81 не работает

                K 1 Reply Last reply Reply Quote 0
                • K
                  Konstanti @Max69
                  last edited by Konstanti

                  @Max69
                  Здр
                  Если я все верно понял, то
                  И не будет работать .
                  При такой реализации ответный пакет всегда будет уходить через шлюз по умолчанию pf Клиента.
                  Это особенность PF при работе через виртуальные интерфейсы (GRE,VTI,OpenVPN,...) Проблему можно решить , используя NAT Outbound на виртуальном интерфейсе PF сервера ,или изменив шлюз по умолчанию на PF клиенте.

                  Те сейчас Ваша схема функционирует так

                  Клиент --> <Интернет> pf Сервер (x.x.x.x)--> <vpn tun10.0.8.x>--> pf Клиент --><lan> Веб сервер(y.y.y.y)

                  Обратно
                  Веб сервер(y.y.y.y)--> <lan> --> pf Клиент --> <Интернет> --> Клиент

                  Результат - соединения нет

                  M 1 Reply Last reply Reply Quote 1
                  • M
                    Max69 @Konstanti
                    last edited by Max69

                    @Konstanti
                    Ok. Однако почему-то пакет не ловится на клиенте вообще.
                    Если запускаю Packet Capture на клиенте, на сервере делаю Test Port 10.0.8.2, то все оk, Packet Capture показывает пакеты.
                    Если же http запрос через браузер то Packet Capture на клиенте вообще ничего не показывает ... т.е. похоже трафик не идет даже в одну сторону. Т.е. с публичного IP не заворачивает в VPN. В fw сервера открыл 81й порт на WAN, сделал редирект на 10.0.8.2, в одну то сторону должен пробрасывать по идее.

                    K 1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @Max69
                      last edited by

                      @Max69
                      Начните отлавливать пакеты с самого начала цепочки

                      1. PF сервер WAN ( порт 81)
                      2. PF сервер VPN интерфейс
                        и тд ....
                      M 1 Reply Last reply Reply Quote 1
                      • M
                        Max69 @Konstanti
                        last edited by Max69

                        @Konstanti
                        Попробовал, интересный эффект, трафик на клиенте ловится с других устройств, а если с самого хоста пф клиента, то трафика нет ... веб-гуи сервера есть, а на другом порту трафика нет ... Аааа, епсель-мопсель, на клиенте же fw, ну усе заработало,

                        Мэни сэнкс ...)

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