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

    Измучился с пробросом портов

    Scheduled Pinned Locked Moved Russian
    58 Posts 12 Posters 21.6k 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.
    • S
      SergeyKA
      last edited by

      @werter:

      Что за ОС на проблемной машине?

      Win 2003

      Telnet на 8888 внутри сети проходит?

      Нет! и nmap его не видит

      У 192.168.0.8 шлюзом pfsense указан ?

      Да.

      Есть ли фаервол (особенно всякие там комплексные Internet Security) на нем ?

      Нету. Мауэр отключен.

      На скрине не вошло, но на этом серваке открыт порт RDP и прекрасно летает.
      На сколько я понимаю у меня проблема не с PFS, а с серваком.
      Блин, засада. Не понимаю, почему не слушается порт.

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

        На сколько я понимаю у меня проблема не с PFS, а с серваком.
        Блин, засада. Не понимаю, почему не слушается порт.

        Первым делом всегда проверяйте доступность порта внутри сети!

        По остальным вопросам обращайтесь на профильный форум своего (проблемного) ПО.

        1 Reply Last reply Reply Quote 0
        • B
          BlackRoger
          last edited by

          В сети есть машина 192.168.0.101 которая показывает web-морду через 80 порт, необходимо подключаться к этой web-морде через нестандартный порт - 555 извне. Шлюз организован на pfsense. Внутри сети все прекрасно работает. Проброс NAT такой:
          Interface - WAN
          Protocol - TCP
          Source Adress - *
          Source Ports - *
          Dest. Adress - WAN adress
          Dest. Ports - 555
          NAT IP - 192.168.0.101
          NAT Ports - 80 (HTTP)
          Другие программы (Radmin, RDP) проброшены по такому же принципу и работают без проблем.

          Если в вышеуказанном правиле "Dest. Adress" прописать порт - 80 (HTTP), все начинает работать. В браузере соответственно уже не указываем "внешний_IP:555", просто "внешний_IP".
          В чем может быть такая странная проблема?

          P.S. В браузере при проверке заходил из другой сети (другой провайдер).

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

            У меня работает подобная комбинация.
            WAN TCP * * * 1111 192.168.0.215 80 (HTTP)
            Попробуйте
            Вместо
            Destination= WAN address
            использовать
            Destination= ANY

            1 Reply Last reply Reply Quote 0
            • B
              BlackRoger
              last edited by

              Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.

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

                Отключите файрволл на 192.168.0.101
                Подымите на 192.168.0.101 еще какую-нибудь службу, если это Виндовс - включите тот же RDP и попробуйте аналогичное на нем, например -  WAN:33398->192.168.0.101:3389

                1 Reply Last reply Reply Quote 0
                • B
                  BlackRoger
                  last edited by

                  Файрвол на 192.168.0.101 выключен, другие службы включая RDP (порт 3389) пробрасываются без проблем. То есть набрав к примеру 89.178.14.21:3555 я подключаюсь по RDP на 192.168.0.101

                  1 Reply Last reply Reply Quote 0
                  • P
                    PbIXTOP
                    last edited by

                    @BlackRoger:

                    Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.

                    А нету ли на pfsense squid'a в прозрачном режиме?

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

                      @PbIXTOP:

                      @BlackRoger:

                      Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.

                      А нету ли на pfsense squid'a в прозрачном режиме?

                      Да, явно что-то мешает.

                      Попутно вопрос. Port forward активно и давно использую. И с мультиваном и без. И ни разу не использовал поле
                      Destination= WAN address (по умолчанию там ANY)
                      И все всегда работает.  Что я делаю не так?

                      1 Reply Last reply Reply Quote 0
                      • B
                        BlackRoger
                        last edited by

                        А нету ли на pfsense squid'a в прозрачном режиме?

                        Стоял - полностью удалил и перезагрузил pfsense. Не помогло
                        Может быть в system \ advanced где-то галочка не там стоит? Сейчас стоят на:
                        Enable webConfigurator login autocomplete
                        Disable HTTP_REFERER enforcement check
                        Enable Secure Shell

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

                          А что насчет WebGUI redirect?
                          У меня эта галка не отмечена.

                          Включите лог для этого правила на WAN.

                          1 Reply Last reply Reply Quote 0
                          • B
                            BlackRoger
                            last edited by

                            WebGUI redirect у меня тоже не отмечена. А где включается лог для этого правила на WAN? И как потом увидеть результат?

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

                              @BlackRoger:

                              WebGUI redirect у меня тоже не отмечена. А где включается лог для этого правила на WAN? И как потом увидеть результат?

                              При создании порт форвард создается правило на WAN, обычно начинается со слова NAT. В нем есть пункт Log packets that are handled by this rule.
                              Смотреть -  Status - System Logs - Firewall

                              1 Reply Last reply Reply Quote 0
                              • B
                                BlackRoger
                                last edited by

                                А что там смотреть "Источник" и "Назначение", больше ничего. Не понятно, почему все остальные порты пробрасываются а именно 80 блочится?

                                1 Reply Last reply Reply Quote 0
                                • B
                                  BlackRoger
                                  last edited by

                                  Попробовал сделать проброс 80 порта на системе Monowall (аналог pfsense), там все сразу заработало без проблем. Так что вывод очевиден - в pfsense где-то стоит секретная галочка.

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

                                    А если использовать не 555, а 5555, например?
                                    И сбросить states\перегрузить pf?

                                    1 Reply Last reply Reply Quote 0
                                    • N
                                      NegoroX
                                      last edited by

                                      ВЕБ морда pfsense  на HTTP или на HTTPS ?

                                      1 Reply Last reply Reply Quote 0
                                      • B
                                        BlackRoger
                                        last edited by

                                        на HTTPS (443 порт), пробовал даже на 10000 порт ее переводил - не помогло.
                                        В NAT переделал правило на 5555 порт, перезагрузил - не помогло.
                                        Кстати, когда заходишь через браузер извне, после IP адреса прописывается xx.xx.xx.xx/index.x?theme=800x480 , то есть он нащупывает web интерфейс и тут же блочит. Просто когда заходишь на устройство из локальной сети в адресной строке присутствует этот же фрагмент среди всего остального.

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

                                          после IP адреса прописывается xx.xx.xx.xx/index.x?theme=800x480 , то есть он нащупывает web интерфейс и тут же блочит. Просто когда заходишь на устройство из локальной сети в адресной строке присутствует этот же фрагмент среди всего остального.

                                          Ничего из вышеописанного не наблюдаю

                                          1 Reply Last reply Reply Quote 0
                                          • B
                                            BlackRoger
                                            last edited by

                                            Отображения в адресной строке могут отличаться. т.к. у нас разные устройства. Тут просто интересен сам факт, что устройство как бы "прощупывается" извне и тут же блочится.

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