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

    PfSense 2.0.1, MultiWAN, шлюз, PPTP на интерфейсе OPT1

    Scheduled Pinned Locked Moved Russian
    8 Posts 2 Posters 3.7k 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
      remark
      last edited by

      Доброго всем здоровья.
      Появилась проблема, связанная с WAN-интерфейсами, находящимися в одной подсети провайдера, шлюзом по умолчанию и PPTP-сервером. Стоит pfSense 2.0.1 (i386). Начну со схемы:

      +------------------+                               +----------------+
      |                  |-----[WAN: xxx.xxx.xxx.12/29]--| default gw     |
      |xxx.xxx.xxx.9/29  |                               |  pfSense       |--[LAN:192.168.40.1/24]---->
      | шлюз провайдера  |                               |                |
      |                  |-----[OPT1:xxx.xxx.xxx.10/29]--| pptp server    |
      +------------------+                               +----------------+
      
      Интерфейс xxx.xxx.xxx.12 - default gateway
      
      

      Оговорюсь, что на роутере с pfSense есть еще интерфейсы, но к теме вопроса они не имеют отношения: это канал Ethernet+PPTP со вторым провайдером (дефолтным шлюзом не является, в failover не участвует) и еще один LAN-интерфейс, в настоящее время отключен.
      Из схемы видно, что два WAN-интерфейса (WAN и OPT1) имеют адреса в одной подсети, выделенной мне провайдером.
      Сделано это для того, чтобы избежать ограничений:

      There are two limitations of PPTP in pfSense, due to limitations in the NAT capabilities of the underlying pf.
      1. If the PPTP server is enabled, no clients behind the firewall can connect to a PPTP server on the Internet if they are NAT'ed to the same public IP as the PPTP server is using.

      Иными словами, удалённые пользователи подключались по PPTP к интерфейсу OPT1 и пользовались благами локальной сети, как то RDP+1С и прочие вкусности. При этом, сидящие в локальной сети могли беспрепятственно подключаться к внешним PPTP-серверам.
      И надо сказать, в 1.2.3 такая схема работала. До сих пор есть старый роутер, оставшийся после апгрейда, на котором стоит pfSense 1.2.3, и если подключить интерфейсы туда, всё заработает.
      Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.
      Анализ трафика (ответы от xxx.xxx.xxx.10) при попытке подключения даёт такую картину:
      на xxx.xxx.xxx.10 (yyy.yyy.yyy.yyy – белый адрес моего домашнего роутера):

      router ~ # tcpdump -i ppp0 -n src xxx.xxx.xxx.10
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
      23:55:07.194699 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: S 2263565803:2263565803(0) ack 2314372289 win 65228 <mss 1460,nop,wscale="" 7,sackok,eol="">
      23:55:07.235669 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 157 win 512
      23:55:07.236454 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: P 1:157(156) ack 157 win 513: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(257) [|pptp]
      23:55:07.278119 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 325 win 511
      23:55:07.279285 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: P 157:189(32) ack 325 win 513: pptp CTRL_MSGTYPE=OCRP CALL_ID(31673) PEER_CALL_ID(57462) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(64000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(0)
      23:55:07.324651 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 349 win 513
      23:55:13.938364 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 373 win 513</mss>
      

      Ага. Есть ответы, но почему только по порту 1723? Где же GRE?
      А вот он где (прошу заметить, что это тоже попытка подключиться к адресу xxx.xxx.xxx.10):

      router ~ # tcpdump -i ppp0 -n src xxx.xxx.xxx.12
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
      00:05:15.902734 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 2, length 54: LCP, Conf-Request (0x01), id 83, length 40
      00:05:17.904353 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 3, length 54: LCP, Conf-Request (0x01), id 84, length 40
      00:05:19.904986 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 4, length 54: LCP, Conf-Request (0x01), id 85, length 40
      00:05:21.905663 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 5, length 54: LCP, Conf-Request (0x01), id 86, length 40
      

      Вот оно что! pfSense отправляет GRE-пакеты с интерфейса xxx.xxx.xxx.12, на котором прописан шлюз по умолчанию.
      Клиенту это не нравится, он ждет пакеты с другого адреса, а эти отпинывает. Потому и не устанавливается PPTP-соединение.

      Получается, что надо прописать интерфейсу xxx.xxx.xxx.10 тот же шлюз, чтобы он сам мог отправлять пакеты, от своего адреса? Но TCP-пакеты ведь идут, и именно с нужного адреса,а GRE - не хотят…
      Почему? Это первый вопрос.
      Пинг на xxx.xxx.xxx.10, кстати, тоже идет нормально, ответы приходят с адреса интерфейса OPT1. И OpenVPN на интерфейсе OPT1 работает нормально.

      Второй вопрос, который я хотел бы задать уважаемым форумчанам – как быть со шлюзом для интерфейса OPT1? Знаю, в англоязычной части форума хором говорят, что нельзя, потому что они в одной подсети. Но в 1.2.3 было можно. Там не было списка выбора шлюзов, там просто было текстовое поле, вносишь туда IP шлюза и радуешься.

      Спасибо.

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

        @remark:

        Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.

        А вот не работает. Почему - не знаю, так и не выяснили. Вообще по 619-й ошибке тут на форуме нету никакого решения.

        Вот почитай мою тему - http://forum.pfsense.org/index.php/topic,44005.0.html

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

          @sweep4:

          @remark:

          Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.

          А вот не работает. Почему - не знаю, так и не выяснили. Вообще по 619-й ошибке тут на форуме нету никакого решения.

          Вот почитай мою тему - http://forum.pfsense.org/index.php/topic,44005.0.html

          Почитал. Грустно всё это, при том, что на 1.2.3 такая схема у меня работала.

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

            Чудо.
            Не знаю почему, но оно заработало. PPTP-клиентом с моего домашнего компьютера (Windows 7) могу законнектиться на и на OPT1 и на WAN, при этом default gateway стоит WAN. Сеть и хосты в удаленном офисе через PPTP-туннель доступны, пингуются и RDP проходит. Ранее на этом же компьютере при попытке законнектиться на адрес OPT1 выходила ошибка 619.
            Если кому интересно, могу интересующие скриншоты и конфиги выложить.
            Сам пока не пойму, что произошло, но конфиг сбэкаплю :)

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

              Вот еще что нашел, может кому пригодится:

              http://support.microsoft.com/kb/271731

              Эта проблема возникает, если сервер PPTP отвечает с IP-адреса, отличного от того, на который компьютер с клиентом PPTP отправил этот запрос. Данная проблема возникает в следующих случаях:

              Сервер имеет несколько IP-адресов в общем сетевом интерфейсе.
                  Используется многосетевой сервер, и настройка основного шлюза производится в неправильном интерфейсе.

              Клиент PPTP обнаруживает разницу между IP-адресом в запросе и в ответе, поэтому не разрешает выполнить подключение, если в ответе сервера PPTP используется другой IP-адрес.

              Чтобы разрешить клиенту PPTP на компьютере под управлением Windows XP с пакетом обновлений 1 (SP1) или Windows 2000 с пакетом обновлений 4 (SP4) или более поздней версии подключаться к серверу PPTP, отвечающему с другого IP-адреса, необходимо отключить подтверждение PPTP-адресов. Для этого выполните следующие действия. Предупреждение. Неправильное изменение параметров системного реестра с помощью редактора реестра или любым иным путем может привести к серьезным неполадкам и к необходимости переустановки операционной системы. Корпорация Майкрософт не гарантирует устранения этих неполадок. Ответственность за изменение реестра несет пользователь.

              Нажмите кнопку Пуск и выберите пункт Выполнить.
                  В поле Открыть введите команду regedit и нажмите кнопку OK.
                  Найдите следующий раздел, где <000x> – сетевой адаптер для драйвера минипорта WAN (PPTP):
                  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}<000x>
                  В меню Правка выберите пункт Создать, а затем Параметр DWORD.
                  Введите имя параметра ValidateAddress и нажмите клавишу ВВОД.

              Примечание. По умолчанию значение параметра равно 0 (отключен).
                  Закройте редактор реестра.
                  Перезагрузите компьютер.

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

                @remark:

                Сам пока не пойму, что произошло, но конфиг сбэкаплю :)

                А поподробнее ? Какие-то настройки делались или само по себе вдруг заработало ? Не слетает ли это чудо, например, после рестарта роутера ? После отвала одного из ван-линков и появления сигнала обратно ?

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

                  С ребутом и отвалами провайдеров пока не экспериментировал.

                  Экспериментировал со шлюзами, потом вернул, как было, и заработало.

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

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

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