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

    Не идет обратный трафик IPSec…

    Scheduled Pinned Locked Moved Russian
    15 Posts 3 Posters 6.1k 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.
    • werterW
      werter
      last edited by

      https://forum.pfsense.org/index.php?topic=58943.0
      Попробуйте добавить разрерающее правило во Floating rules

      P.s. Еще , как вариант :

      Go to the webinterface of your pfSense box

      Go to System and then to Advanced in the top menu
      Click on the Firewall / NAT tab
      Change the setting of Firewall Optimization Options to conservative

      1 Reply Last reply Reply Quote 0
      • L
        Lazy caT
        last edited by

        Спасибо за совет… :)

        Не работает... :(
        @werter:

        https://forum.pfsense.org/index.php?topic=58943.0
        Попробуйте добавить разрерающее правило во Floating rules

        Добавил в "Firewall:Rules" -> "Floating" правило:

        Pass IPv4 TCP 	VLAN_18_IF net 	3389 (MS RDP) 	* 	* 	* 	none 
        

        всё равно, блокируется все исходящие MS:RDP Proto TCP:SA…

        @werter:

        Go to the webinterface of your pfSense box

        Go to System and then to Advanced in the top menu
        Click on the Firewall / NAT tab
        Change the setting of Firewall Optimization Options to conservative

        Это, к сожалению, тоже не помогает… :(

        1 Reply Last reply Reply Quote 0
        • L
          Lazy caT
          last edited by

          СТОП…

          ЗАРАБОТАЛО...  :D

          Изменил в "Firewall:Rules" -> "Floating" правило:

          Pass IPv4 TCP 	VLAN_18_IF net 	3389 (MS RDP) 	* 	* 	* 	none 
          

          добавил ещё TCP flags: Any flags. и ЗАРАБОТАЛО….

          Спасибо, werter, за наводку... ОГРОМНОЕ СПАСИБО...


          Вот тут, прошу прощения, ошибочка...
          Правило такое стало:

          Pass IPv4	*	*	*	* 	* 	* 	none 
          

          и ещё TCP flags: Any flags.

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

            Рад что получилось. Сам возьму на заметку  ;D

            1 Reply Last reply Reply Quote 0
            • L
              Lazy caT
              last edited by

              @werter:

              Рад что получилось. Сам возьму на заметку  ;D

              Похоже рано я порадовался… :(

              Подключение происходит НО...
              Видимо, после того как время действия правила проходит, подключение рвется...

              Точнее, рвется через 15-20 секунд после подключения...
              Потом через полторы минуты (точнее не засекал) переподключается...
              Потом опять через 15-20 секунд, рвется опять... ну и т.д....

              Сейчас буду копать...


              Ещё заметил такую вещь...

              Когда я подключаюсь по RDP к удаленному компьютеру (192.168.18.3), если никаких действий в RDP окне
              не предпринимать, т.е. мышкой не двигать, окна не открывать и т.д. то подключение не рвется продолжительное время...

              Как заметил: запустил на удаленной машине системные часы...
              Пока я ничего не трогал, секундомер "тикал", как только начинал "елозить" мышкой по удаленному Раб.столу,
              секундомер, через 15 сек., умирал... А через 90 сек. оживал...

              Кстати, настройка параметра "Firewall Optimization Options" в "System: Advanced: Firewall and NAT", никакого эффекта
              не дает... :(

              1 Reply Last reply Reply Quote 0
              • S
                SysR
                last edited by

                1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
                2. На интерфейсе  VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.

                IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.

                Какие сообщения IPSec?
                Покажите конфирурацию файрвола.
                А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола?

                1 Reply Last reply Reply Quote 0
                • L
                  Lazy caT
                  last edited by

                  @SysR:

                  1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
                  2. На интерфейсе  VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.

                  Конфигурация правил firewall'а указана выше… Там ничего не менялось...

                  @SysR:

                  IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.

                  С провайдерами всё впорядке… и с IPSec'ом и с UDP тоже всё впорядке... к тому же, были бы проблемы с провайдерами и хождением UDP туннель бы не поднимался, и я бы здесь другие вопросы задавал...

                  К тому же, на том же FreeBSD сервере, который участвует в связке с pfSense'ом, поднят основной IPSec туннель только уже между двумя FreeBSD (моим домашнем шлюзом и основным шлюзом конторы, на котором поднято 12 IPSec туннелей) с, соответствующим образом, настроенным ipfw... никаких проблем... туннель между двумя подсетями 192.168.5.0/28 и подсетью 192.168.10.0/24, работает исправно... все пакеты ходят туда и обратно без проблем...

                  @SysR:

                  Какие сообщения IPSec?

                  Никаких… У IPSec всё чисто... и вообще, при чем здесь IPSec?...
                  Два сервака устанавливают подключение меж собой?... Устанавливают...
                  Трафик внутри туннеля ходит?... Ходит... (см. выше: ICMP ходит в обе стороны без проблем...)
                  IPSec не валится... это проверено... при "вылете" RDP, ping на тот же хост не прерывается...

                  @SysR:

                  Покажите конфирурацию файрвола.

                  Конфигурация правил firewall'а указана выше… Там ничего не менялось...

                  @SysR:

                  А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола?

                  если бы rdp рвал бы подключения он бы вылетал сам с ошибкой… а так, нет... не вылетает...

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

                    @ Lazy caT

                    Не оно ли ?

                    https://redmine.pfsense.org/issues/1841

                    Martin Saini wrote:

                    Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?

                    I managed to get ours working by adding a 'floating' rule in the web interface. We have an allow all rule already on the GRE interface, but the state tracking seemed broken on this, I found a hint somewhere saying to add an allow all 'floating' rule, with interface set to the GRE interface, and direction set to any. Also, note that both the rule on the GRE interface, and the floating rule have advanced option 'State Type' set to 'none'.

                    looking at the generated pf rules, the following two rules result from this:
                    pass quick on gre0 all no state label "USER_RULE: Allow all traffic over xxxx"
                    pass in quick on gre0 all no state allow-opts label "USER_RULE: Allow all internal xxxx traffic"

                    The first rule us the floating rule, it seems to be the one that makes it work. So I guess there's something funny about it that make the direction (in) bit on the second rule be insufficient.

                    Hope this helps

                    1 Reply Last reply Reply Quote 0
                    • L
                      Lazy caT
                      last edited by

                      @SysR:

                      Тогда попробуйте объяснить самому себе почему в логах файрвола появляются записи с действием block.

                      Тут всё нормально… фактически, в логах firewall'а записи о блокировках не появляется... :)

                      Уже не появляются... Когда я создал динамическое правило...

                      
                      Pass IPv4	*	*	*	* 	* 	* 	none  TCP flags: Any flags.
                      
                      

                      Но, вот тут есть одно НО…

                      На сколько я осведомлен в работе firewall'ов, у каждого динамического правила есть так называемый lifetime...
                      Так вот, когда этот lifetime "оттикает", правило удаляется из таблицы динамических правил... и... происходит то
                      что происходит... Т.е. "вешается" RDP, до реконнекта (по моему, у winsock подключений дефолтный
                      timeout около 60 или 90 сек.?) и создания нового правила после реконнекта...

                      И к тому же, создание постоянного, идентичного динамическому, правила в разделе IPSec, эффекта, к сожалению, никакого не даёт. Это уже проверено...

                      Во, а может Вы попробуете мне объяснить, по сути проблемы?
                      Как, исходя из написанного мною выше, в данном топике, как сделать так чтобы не RDP не "вешался"?

                      Спасибо.

                      1 Reply Last reply Reply Quote 0
                      • L
                        Lazy caT
                        last edited by

                        @werter:

                        @ Lazy caT

                        Не оно ли ?

                        https://redmine.pfsense.org/issues/1841

                        Martin Saini wrote:

                        Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?

                        I managed to get ours working by adding a 'floating' rule in the web interface. We have an allow all rule already on the GRE interface, but the state tracking seemed broken on this, I found a hint somewhere saying to add an allow all 'floating' rule, with interface set to the GRE interface, and direction set to any. Also, note that both the rule on the GRE interface, and the floating rule have advanced option 'State Type' set to 'none'.

                        looking at the generated pf rules, the following two rules result from this:
                        pass quick on gre0 all no state label "USER_RULE: Allow all traffic over xxxx"
                        pass in quick on gre0 all no state allow-opts label "USER_RULE: Allow all internal xxxx traffic"

                        The first rule us the floating rule, it seems to be the one that makes it work. So I guess there's something funny about it that make the direction (in) bit on the second rule be insufficient.

                        Hope this helps

                        Во, ещё раз, спасибо… :)
                        Scenario 2 очень похоже на мой случай... :) Сейчас буду читать-разбираться...

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

                          Pass IPv4 * * * * * * none  TCP flags: Any flags.

                          Внимательнее! Должно быть TCP flags: none

                          1 Reply Last reply Reply Quote 0
                          • L
                            Lazy caT
                            last edited by

                            @werter:

                            Pass IPv4 * * * * * * none  TCP flags: Any flags.

                            Внимательнее! Должно быть TCP flags: none

                            Неа, вот тут не соглашусь… :)

                            В моём случае, работает динамическое правило с установленными TCP флагами…
                            Если "флаги" в none правило не срабатывает… Проверял...
                            У меня же блокируются исходящие TCP SYN/ACK... Поэтому, если флаги убрать, траффик под правило
                            подпадать не будет ни разу...

                            1 Reply Last reply Reply Quote 0
                            • L
                              Lazy caT
                              last edited by

                              И так, подытожу свои разбирательства со всем тем, что было описано выше…

                              Для корректной работы MS RDP, и не только RDP (а всего что связывается с блокировкой возвращающегося TCP, с флагами SYN/ACK), необходимо добавить "Floating" "Firewall:Rules"

                              Firewall rule

                              • Action: Pass

                              • Interface: IPSec

                              • Direction: any

                              • TCP/IP Version: IPv4

                              • Protocol: TCP

                              • Source: any

                              • Destination: any

                              • Destination port range: any

                              Advanced features

                              • TCP flags: Any flags

                              • State Type: none

                              Это финальный вариант, который был "подсмотрен" в посте от werter, вот эта выдержка:

                              …and the floating rule have advanced option 'State Type' set to 'none'…

                              На данный момент, RDP работает, пока не "вешается", уже как с полчаса…
                              Слежу далее за работой... :)

                              Огромное спасибо всем за советы и предложения...
                              Отдельное СПАСИБО тов. werter, за конструктивные предложения… :)

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

                                Еще раз - пожалуйста.

                                P.s. И таки да , именно в 'State Type' необходим 'none' . Невнимательно глянул, пардон.

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