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

    Не отрабатывает проброс произвольных портов с WAN в LAN

    Scheduled Pinned Locked Moved Russian
    29 Posts 3 Posters 2.7k 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
      marchello
      last edited by

      Пробросил 80 порт без проблем с внешки внутрь. По той же схеме попытался прокинуть ftp с внешки на внутренний сервер правда с использованием нестандартного порта + диапазона портов для Passive mode. Не хочет работать. На сервере в качестве gate стоит pfSense. На самом pfSense в логах фиксируется что соединение идёт но завершается CLOSED:SYN_SENT и в логах самого FileZilla Server не видно позывов к подключению, то есть пакеты не натируются внутрь сети. Почему такое может происходить или нужно как то хитро прокидывать соединение для Passive mode. А ещё не понятно как заставить psSense работать с пробросом VNC с внешки внутрь если на клиентской машине указывается гейт не шлюз pfSense. На Kerio Connect такой вариант работал вообще без проблем.

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

        @marchello
        Скрины настроек пф (ЛАН, ВАН, Порт форврд) + скрины настроек FZ.

        А ещё не понятно как заставить psSense работать с пробросом VNC с внешки внутрь если на клиентской машине указывается гейт не шлюз pfSense. На Kerio Connect такой вариант работал вообще без проблем.

        Почему шлюзом не может\не должен быть пф в вашем случае? Объясните. Уверен, что можно решить и с пф в кач-ве шлюза.

        1 Reply Last reply Reply Quote 0
        • M
          marchello
          last edited by

          Alias.JPG
          WAN.JPG
          LAN.JPG
          PortForward.JPG

          В настройках pfSense d в части Firewall & NAT ничего не менял всё дефолтовое. Использовать второй шлюз в составе pfSense к сожалению нельзя в силу причин шифрации трафика КШ "Застава" и закрытости сети. На клиенте гейт либо в сторону КШ "Застава" либо в сторону pfSense. Так-то я организовал авторизацию через LDAP и портал отрабатывает нормально. И доступ к внутреннему WEB серверу работает тоже без проблем а вот с ftp что то затроило, да и VNC тоже, хотя если гейт на клиенте как рекомендовано сменить на pfSense то работает, однако так не вариант делать потому как гейт Заставы в прерогативе по любому. Подскажите как заставить ftp по нестандартному 4915 ... на внутренний сервер ходить где гейтом прописан не pfSense?

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

            @marchello Натировать пакеты от PFSense на lan интерфейсе ,чтобы на внутренний сервер приходили пакеты с адресом источника lan интерфейса PF . Тогда внутренний сервер будет отвечать на lan интерфейс PF , а тот , в свою очередь , дальше наружу

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

              @Konstanti То есть нужно переключить NAT в ручной режим и принудительно добавить правило?

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

                @marchello Совершенно верно
                Добавляете правило для исходящего Нат на LAN интерфейсе
                и избавляетесь от внешней ip адресации внутри Вашей сети для внутреннего сервера
                Если все сделаете верно , то внутренний сервер будет отвечать на LAN интерфейс PF, а тот уже дальше
                Схема будет выглядеть так
                8.8.8.8 -> 1.1.1.1 (внешний ip PF, проброс 10.10.10.11 ) -> 10.10.10.10 ( внутр ip LAN PF, меняем адрес источника) -> 10.10.10.11 (внутр сервер)
                и обратно
                10.10.10.11 ->10.10.10.10 -> 1.1.1.1 -> 8.8.8.8

                Вот как это выглядит у меня в варианте Linux ( iptables)
                Смысл , думаю , ясен
                048c8823-9d59-44d3-b502-8a96bc3239aa-image.png

                M 2 Replies Last reply Reply Quote 0
                • M
                  marchello @Konstanti
                  last edited by

                  @Konstanti Спасибо за подсказку, завтра заскочу на работу и попробую провернуть авантюру )

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

                    @Konstanti Попробовал переключив NAT в гибридный режим и создав вот такое правило:
                    NAT-15062019.JPG

                    Нет не хочет работать (((

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

                      @marchello

                      1. уверены , что порт источника 4915 (посмотрите мой пример с Linux, вторая строка - это именно NAT ) ????
                      2. попробуйте Manual Outbound NAT

                      e85b6e4d-0ee8-43de-aa22-db50b46b5b90-image.png

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

                        @Konstanti Ну это по факту 21 порт ftp в режиме пассив с выделением дополнительных портов 4920-4930 но по старой привычке я на сервере обычно меняю стандартный порт 21 на иной )

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

                          @marchello
                          Я про то , что Вы создали правило с портом источника 4915, а по факту порт источника может быть любым. А вот порт назначения - да , 4915.

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

                            @marchello said in Не отрабатывает проброс произвольных портов с WAN в LAN:

                            Использовать второй шлюз в составе pfSense к сожалению нельзя в силу причин шифрации трафика КШ "Застава" и закрытости сети. На клиенте гейт либо в сторону КШ "Застава" либо в сторону pfSense

                            А на Заставе завернуть ВСЕ, что идет с определенного IP на пф разве нельзя? Попробуйте.

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

                              @werter Заставу напрямую нам не дают рулить у нас ограниченные права ( к большому нашему сожалению

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

                                @Konstanti С портом источника я пробовал и any это не повлияло на результат. Прямое указание 4915 это скорее жест отчаяния )))

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

                                  @marchello Значит что-то делаете неверно
                                  Tcpdump надо запускать на lan интерфейсе
                                  и смотреть , что происходит (например , посмотреть в каком виде уходят пакеты на нужном Вам порту в сторону внутреннего ftp-сервера )
                                  Еще раз обращаю внимание на мой скриншот
                                  1 строка - проброс портов на внутренний портовый сервер 192.168.1.230 ( источник пакета не важен , важен порт назначения на внешнем интерфейсе)
                                  2 строка - натирование исходящих проброшенных пакетов на интерфейсе tun100 c адресом назначения 192.168.1.230

                                  Вот как это выглядит через призму tcpdump
                                  на внешнем интерфейсе
                                  17.58.63.172.22715 > 37.XXX.XXX.XXX.smtp: Flags [S], seq 3057509191, win 29200, options [mss 1460,sackOK,TS val 2982516424 ecr 0,nop,wscale 7], length 0
                                  37.XXX.XXX.XXX.smtp > 17.58.63.172.22715: Flags [S.], seq 82960713, ack 3057509192, win 14480, options [mss 1346,sackOK,TS val 2733787062 ecr 2982516424,nop,wscale 7], length 0

                                  и внутреннем

                                  10.10.100.2.22715 > 192.168.1.230.smtp: Flags [S], seq 3057509191, win 29200, options [mss 1360,sackOK,TS val 2982516424 ecr 0,nop,wscale 7], length 0
                                  192.168.1.230.smtp > 10.10.100.2.22715: Flags [S.], seq 82960713, ack 3057509192, win 14480, options [mss 1346,sackOK,TS val 2733787062 ecr 2982516424,nop,wscale 7], length 0

                                  M 2 Replies Last reply Reply Quote 0
                                  • M
                                    marchello @Konstanti
                                    last edited by

                                    @Konstanti Завтра попробую

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

                                      @marchello said in Не отрабатывает проброс произвольных портов с WAN в LAN:

                                      Пробросил 80 порт без проблем с внешки внутрь

                                      Если вы 80-й пробрасывали НЕ для пф, то КРАЙНЕ рекомендую сменить дефолтный порт вебки пф на нестандартный. Плюс откл. авторедирект для вебки пф и РАЗРЕШИТЬ доступ к вебке только с определенных IP. И пользовать httpS, ес-но.

                                      Касаемо ФТП. Шлюзом у вашего ФТП должен быть пф. Проверьте это. Проблем быть в таком случае не должно.
                                      И самое важное. Если на пф не вкл. nat loopback, то проверять доступ ИЗВНЕ к проброшенным портам на пф нужно только с др. провайдера (напр., с моб. тел.)

                                      https://forum.netgate.com/topic/99643/port-forwarding-with-nat-to-internal-ip-with-different-default-gateway/

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

                                        @werter А если гейт на клиенте в локалке не ip pfSense, работать не будет доступ из внешки на клиента в локале?

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

                                          @marchello

                                          @Konstanti вам предложил схему. Попробуйте.

                                          Кстати, современные ОС дают возможность пользовать n-ое кол-во GW. И даже приоритезировать GW с помощью metric. Попробуйте задать в настройках проблемной машины основной Gw с метрикой 1 (Застава) и резервный с метрикой 100 (пф). Костыль, но может сработать.

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

                                            @werter Это не отрабатывает, только вариант первый гейт пропал - подключаю следующий по весу.

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