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

    Проблема в доступе клиента к одной из сети

    Russian
    5
    41
    8.7k
    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.
    • A
      aka_daemon
      last edited by

      Правило одно, разрешающее все.
        Все таки склоняюсь к тому, что проблема на pfsense04 заключается в multiwan, настроенный в режиме failover, потому как если оставить один интерфейс, то все нормально работает.
        Но нет возможности просто оставить один wan, кот. по статике, так как инет по нему очень дорогой, по этому перешли на yota и провайдер монополист не пускает других на свою территорию.
        Находимся на производстве, где только один провайдер, он же арендодатель производственных помещений.

      1 Reply Last reply Reply Quote 0
      • D
        dima_k
        last edited by

        @aka_daemon:

        скрин исправленного
        сброс не делал, но попробую перезагрузить шлюз.

        верно, multiwan - в тех правилах, где werter говорил о необходимости указать явно шлюз - указана группа OSNOVA, где WANGW (куда приходит openVPN) будет задействован только когда YOTAGW будет не доступен. В правилах для сетей за pfsense01 нужно указать gateway WANGW, и их можно объединить в одно правило с помощью алиаса для этих стетей

        1 Reply Last reply Reply Quote 0
        • D
          dima_k
          last edited by

          @aka_daemon:

          Правило одно, разрешающее все.
            Все таки склоняюсь к тому, что проблема на pfsense04 заключается в multiwan, настроенный в режиме failover, потому как если оставить один интерфейс, то все нормально работает.
            Но нет возможности просто оставить один wan, кот. по статике, так как инет по нему очень дорогой, по этому перешли на yota и провайдер монополист не пускает других на свою территорию.
            Находимся на производстве, где только один провайдер, он же арендодатель производственных помещений.

          Может есть возможность пустить тогда и OpenVPN через yota (это подключение что из себя представляет?)?

          1 Reply Last reply Reply Quote 0
          • A
            aka_daemon
            last edited by

            верно, multiwan - в тех правилах, где werter говорил о необходимости указать явно шлюз - указана группа OSNOVA, где WANGW (куда приходит openVPN) будет задействован только когда YOTAGW будет не доступен. В правилах для сетей за pfsense01 нужно указать gateway WANGW

            наверное вы имели ввиду pfsense04, вместо группы OSNOVA и жёстко указывал шлюзом WANGW, все тоже, в сеть не пускает.

            можно объединить в одно правило с помощью алиаса для этих стетей

            вот здесь не понял, поясните

            1 Reply Last reply Reply Quote 0
            • A
              aka_daemon
              last edited by

              @dima_k:

              подключение можно пустить, но оно не стабильно держится. интерфейс yota связан с роутером yota

              1 Reply Last reply Reply Quote 0
              • D
                dima_k
                last edited by

                @aka_daemon:

                верно, multiwan - в тех правилах, где werter говорил о необходимости указать явно шлюз - указана группа OSNOVA, где WANGW (куда приходит openVPN) будет задействован только когда YOTAGW будет не доступен. В правилах для сетей за pfsense01 нужно указать gateway WANGW

                наверное вы имели ввиду pfsense04, вместо группы OSNOVA и жёстко указывал шлюзом WANGW, все тоже, в сеть не пускает.

                да, все это относится к pfsense04.

                А в Diagnostics: Packet Capture на pfsense04 на интерфейсе openVPN все ли пакеты приходят и уходят если пинговать:

                1. сам pfsense04
                2. сервер 1С

                Если пакеты есть - попробуйте указать Level of Detail = Full, может быть там увидится какая-либо ошибка. Приходилось встречать, последнее например, ошибка ipsec - bad chsum. При  Level of Detail = Normal ошибки чексуммы пакета не видел.

                1 Reply Last reply Reply Quote 0
                • D
                  dima_k
                  last edited by

                  @aka_daemon:

                  можно объединить в одно правило с помощью алиаса для этих стетей

                  вот здесь не понял, поясните

                  Думал и так понятно…. Имел в виду, что по отношению к pfsense04 локальные сети, который маршрутизируются в сторону pfsense01 лично я бы объединил в alias (Firewall: Aliases) (вижу, что уже используется в правилах собственный алиас, и он только один - mailru)

                  Создать алиас LanNet_on_pfSense01 и добавить туда сети: 192.168.4.0/24; 192.168.2.0/24; 10.8.0.0/24. Затем уже можно в Firewall на вкладке Lan указать правило Source:LAN net -> Destination: LanNet_on_pfSense01 (наш алиас) Gateway:WANGW.

                  А так получается на скринах 3 одинаковых правила, где меняются подсети: растет число правил и увеличивается время на их изменение (если потребуется)

                  1 Reply Last reply Reply Quote 0
                  • A
                    aka_daemon
                    last edited by

                    А в Diagnostics: Packet Capture на pfsense04 на интерфейсе openVPN все ли пакеты приходят и уходят если пинговать:

                    1. сам pfsense04
                    2. сервер 1С

                    Если пакеты есть - попробуйте указать Level of Detail = Full, может быть там увидится какая-либо ошибка. Приходилось встречать, последнее например, ошибка ipsec - bad chsum. При  Level of Detail = Normal ошибки чексуммы пакета не видел.

                    вот данные:
                    12:32:56.170974 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8717, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 113, length 40
                    12:32:56.171060 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 3245, offset 0, flags [none], proto ICMP (1), length 60)
                        10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 113, length 40
                    12:32:57.173471 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8724, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 114, length 40
                    12:32:57.173506 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 53188, offset 0, flags [none], proto ICMP (1), length 60)
                        10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 114, length 40
                    12:32:58.175400 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8755, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 115, length 40
                    12:32:58.175439 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 14563, offset 0, flags [none], proto ICMP (1), length 60)
                        10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 115, length 40
                    12:32:59.177588 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8760, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 116, length 40
                    12:32:59.177628 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 9004, offset 0, flags [none], proto ICMP (1), length 60)
                        10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 116, length 40
                    12:33:03.084690 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8818, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 117, length 40
                    12:33:07.729089 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8893, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 118, length 40
                    12:33:12.731428 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8982, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 119, length 40
                    12:33:17.731690 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 9052, offset 0, flags [none], proto ICMP (1), length 60)
                        10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 120, length 40

                    ![packet capture.jpg](/public/imported_attachments/1/packet capture.jpg)
                    ![packet capture.jpg_thumb](/public/imported_attachments/1/packet capture.jpg_thumb)

                    1 Reply Last reply Reply Quote 0
                    • A
                      aka_daemon
                      last edited by

                      сделал алиас, как вы и советовали. жестко выставил шлюзом wangw, доступа к локалке 10.2.2.0/24 нет. при такой настройке пропал доступ к сетям 192.168.2.0/24 и 192.168.4.0/24 из 10.2.2.0/24

                      1 Reply Last reply Reply Quote 0
                      • D
                        dima_k
                        last edited by

                        @aka_daemon:

                        А в Diagnostics: Packet Capture на pfsense04 на интерфейсе openVPN все ли пакеты приходят и уходят если пинговать:

                        1. сам pfsense04
                        2. сервер 1С

                        Если пакеты есть - попробуйте указать Level of Detail = Full, может быть там увидится какая-либо ошибка. Приходилось встречать, последнее например, ошибка ipsec - bad chsum. При  Level of Detail = Normal ошибки чексуммы пакета не видел.

                        вот данные:
                        12:32:56.170974 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8717, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 113, length 40
                        12:32:56.171060 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 3245, offset 0, flags [none], proto ICMP (1), length 60)
                            10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 113, length 40
                        12:32:57.173471 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8724, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 114, length 40
                        12:32:57.173506 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 53188, offset 0, flags [none], proto ICMP (1), length 60)
                            10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 114, length 40
                        12:32:58.175400 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8755, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 115, length 40
                        12:32:58.175439 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 14563, offset 0, flags [none], proto ICMP (1), length 60)
                            10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 115, length 40
                        12:32:59.177588 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8760, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.5: ICMP echo request, id 1, seq 116, length 40
                        12:32:59.177628 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 9004, offset 0, flags [none], proto ICMP (1), length 60)
                            10.2.2.5 > 10.8.0.10: ICMP echo reply, id 1, seq 116, length 40
                        12:33:03.084690 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8818, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 117, length 40
                        12:33:07.729089 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8893, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 118, length 40
                        12:33:12.731428 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 8982, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 119, length 40
                        12:33:17.731690 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 9052, offset 0, flags [none], proto ICMP (1), length 60)
                            10.8.0.10 > 10.2.2.203: ICMP echo request, id 1, seq 120, length 40

                        ok. Видим что пакеты приходят, а вот ответа уже нет. Теперь нужно найти: 1) отправляет ли что pfsense04 в lan и 2) принимает ли что хост 10.2.2.203

                        @aka_daemon:

                        сделал алиас, как вы и советовали. жестко выставил шлюзом wangw, доступа к локалке 10.2.2.0/24 нет. при такой настройке пропал доступ к сетям 192.168.2.0/24 и 192.168.4.0/24 из 10.2.2.0/24

                        Что-то с алиасом напутано значит. Когда правила работают, то и должны также работать если просто была замена CIDR на его алиас

                        отписал в личку

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

                          Yota - Tier 1.  Получается , что это соединение приоритетнее WAN. Так надо?

                          Далее. Настоятельно рекомендую сперва попытаться решить проблему используя один линк. И этот линк - WAN.
                          И только после этого работать с группой.

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

                            2 aka_daemon

                            Попробуйте добавить на pfsense04 настройках OpenVPN в Advanced … директиву route 10.10.10.0 255.255.255.0;

                            1 Reply Last reply Reply Quote 0
                            • A
                              aka_daemon
                              last edited by

                              @werter:

                              Yota - Tier 1.  Получается , что это соединение приоритетнее WAN. Так надо?

                              через yota пользователи выходят в инет, так дешевле чем через выделенный канал, берут 20тыс. за 6 мегабит

                              Далее. Настоятельно рекомендую сперва попытаться решить проблему используя один линк. И этот линк - WAN.
                              И только после этого работать с группой.

                              если убрать балансировку и оставить один канал через статический wan, то все работает.

                              1 Reply Last reply Reply Quote 0
                              • A
                                aka_daemon
                                last edited by

                                @werter:

                                2 aka_daemon

                                Попробуйте добавить на pfsense04 настройках OpenVPN в Advanced … директиву route 10.10.10.0 255.255.255.0;

                                если вы имели ввиду маршрут в сеть 10.8.0.0/24, то он уже есть

                                1 Reply Last reply Reply Quote 0
                                • R
                                  remark
                                  last edited by

                                  @aka_daemon:

                                  @werter:

                                  2 aka_daemon

                                  Попробуйте добавить на pfsense04 настройках OpenVPN в Advanced … директиву route 10.10.10.0 255.255.255.0;

                                  если вы имели ввиду маршрут в сеть 10.8.0.0/24, то он уже есть

                                  OpenVPN, насколько я помню, имеет свою, внутреннюю таблицу маршрутизации.
                                  Если добавлять просто системные маршруты, может не заработать. Пропишите маршруты в конфигурации OpenVPN, он сам добавит их в общую таблицу маршрутизации.

                                  И ещё. Смотрю, тут используется конфигурация multi-wan. Проблем с установкой соединения нет? OpenVPN может отбрасывать пакеты, приходящие с IP отличного от того, с которым было установлено соединение (так бывает при multi-wan конфигурации). Если такое происходит, добавьте в конфигурацию OpenVPN параметр float.

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    aka_daemon
                                    last edited by

                                    Пропишите маршруты в конфигурации OpenVPN, он сам добавит их в общую таблицу маршрутизации.

                                    все маршруты через openvpn и прописаны, см. выше

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      aka_daemon
                                      last edited by

                                      И ещё. Смотрю, тут используется конфигурация multi-wan. Проблем с установкой соединения нет? OpenVPN может отбрасывать пакеты, приходящие с IP отличного от того, с которым было установлено соединение (так бывает при multi-wan конфигурации). Если такое происходит, добавьте в конфигурацию OpenVPN параметр float

                                      multi-wan используется на стороне клиента  - pfsense04
                                      серверная часть поднята на pfsense01, см. рисунок

                                      параметр float полезен когда идёт подключение к компьютеру имеющему динамический IP адрес.

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

                                        @aka_daemon:

                                        @werter:

                                        2 aka_daemon

                                        Попробуйте добавить на pfsense04 настройках OpenVPN в Advanced … директиву route 10.10.10.0 255.255.255.0;

                                        если вы имели ввиду маршрут в сеть 10.8.0.0/24, то он уже есть

                                        Нет. Зачем вообще добавлять маршрут в vpn-сеть 10.8.0.0/24 ? Удалите его на pfsense04 и добавьте вместо него route 10.10.10.0 255.255.255.0; на pfsense04. Это ведь реальная локальная сеть проблемного клиента как я понимаю?

                                        1 Reply Last reply Reply Quote 0
                                        • A
                                          aka_daemon
                                          last edited by

                                          проблему решили благодаря dima_k, дело оказалось в маске сети на стороне pfsense04. поменяли маску на хосте 10.2.2.203 с 255.0.0.0 на 255.255.255.0
                                          тему можно закрывать

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