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

    Проблема с доступом к ресурсам через ipsec

    Scheduled Pinned Locked Moved Russian
    7 Posts 4 Posters 691 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.
    • R
      rodley
      last edited by

      Есть один офис. Стоит pfsense 2.4.4, подсеть 192.168.0.0/24
      Есть несколько офисов, подключенные через ipsec к этому офису, на других концах в качестве роутеров pfsense, cisco, draytek и подсети 192.168.x.0/24
      Проблема следующая. В каждой подсети есть различные сервисы, как-то web, rdp, 1с сервера. Из подсети 192.168.0.0 в других подсетях всё доступно. Из других подсетей доступ по rdp и к серверу 1С есть, а к web серверам и по ssh линуксовым машинам нет. При этом пинг на соответствующие сервера есть. Если к сети подключаться через OpenVPN - все ресурсы доступны. Подскажите, в чём может быть проблема.

      1 Reply Last reply Reply Quote 0
      • V
        vladimirlind
        last edited by

        Правила фаервола на IPsec интерфейсе покажите, пожалуйста. Запустите packet capture на ipsec и на внутреннем интерфейсе c 192.168.0.0/24, отфильтровав трафик к вебсерверам и ssh - посмотрите, где затыкается прохождение пакетов. Возможно, имеет смысл выставить MSS clamping на 1300 в IPsec>Advanced (а также на других пирах ipsec), чтобы исключить фрагментацию пакетов.

        R werterW 2 Replies Last reply Reply Quote 1
        • R
          rodley
          last edited by

          6dcb1c66-108c-453e-8c9b-36f24f8d8035-image.png

          1 Reply Last reply Reply Quote 0
          • R
            rodley @vladimirlind
            last edited by

            @vladimirlind said in Проблема с доступом к ресурсам через ipsec:

            Возможно, имеет смысл выставить MSS clamping на 1300 в IPsec>Advanced (а также на других пирах ipsec), чтобы исключить фрагментацию пакетов.

            Да, это помогло. Спасибо огромное!

            viktor_gV 1 Reply Last reply Reply Quote 1
            • werterW
              werter @vladimirlind
              last edited by werter

              Сталкивался с таким (
              У меня это был "привет" от провайдера на одном из концов туннеля ,к-ый выставил неверный mtu на своем оборудовании.

              Обнаружил в лоб ping-ом:

              ping -l xxxx -f -t y.y.y.y,

              где xxxx - размер пакета в байтах, y.y.y.y - ip-адрес на др. конце проблемного туннеля.
              xxxx уменьшаем (начиная, напр, с 1472 = 1500 - 28 ) до пропадания ошибки "Требуется фрагментация пакета, но установлен запрещающий флаг". Однако, есть и минус. Он в том, что завтра очередной "умник" может выставить неверное значение mtu на провайдерском оборудовании. И установка заведомо меньшего значения макс. размера пакета, как и было посоветовано выше, спасет ситуацию в этом случае.

              V 1 Reply Last reply Reply Quote 0
              • V
                vladimirlind @werter
                last edited by

                @werter Если IPsec поверх adsl (c pppoe) пускать такая ситуация может возникнуть - pppоe отъедает 8 байт от езернетовского 1500. Или gre еще вкрутить - минус 24 байта.
                Не помню точно арифметику заголовков - но да, 1300 это оверкилл слегка. Кажется, в районе 1380 должна ошибка пропасть при пинге с флагом на запрет фрагментации.

                1 Reply Last reply Reply Quote 0
                • viktor_gV
                  viktor_g Netgate @rodley
                  last edited by

                  @rodley максимальный размер payload можно определить с консоли pfsense:

                  ping -D -g 1400 -G 1500 x.x.x.x

                  где x.x.x.x - ip на другом конце туннеля
                  вычитаете из полученного значения 20 и вот ваш MSS

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