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

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

    Scheduled Pinned Locked Moved Russian
    41 Posts 5 Posters 9.5k 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.
    • 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.