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

    Site-to-site VPN между Kerio Control и pfSense

    Scheduled Pinned Locked Moved Russian
    32 Posts 4 Posters 10.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.
    • P
      pigbrother
      last edited by

      Не пойму, чего не хватает.
      Удаленная сеть 192.168.0.0 с маской 255.255.248.0 - т.е 192.168.0.0/21
      Доступ нужен к IP 192.168.0.176,192.168.0.177,192.168.0.178

      Поднимаю соединение.  Получаю IP 192.168.25.9 и шлюз 192.168.25.1.

      Маршруты:
      192.168.0.180 192.168.25.1 UGHS 934 1400 l2tp2
      192.168.7.4 192.168.25.1 UGHS 934 1400 l2tp2
      192.168.25.1 link#13 UH 4711 1400 l2tp2
      192.168.25.9 link#13 UHS 0 16384 lo0

      С L2TP-интерфейса  pfSense 192.168.0.176-178 пингуются. С LAN-интерфейса  - нет

      Создаю в NAT: Outbound правило:
      L2TP 10.0.2.0/24 * 192.168.0.0/21 * L2TP address * NO

      L2TP - L2TP-интерфейс
      10.0.2.0/24 - моя LAN

      192.168.0.176-178 - по прежнему недоступны.

      Поднимал соединение на Windows. Работало только после добавление вручную вот такого маршрута
      route add 192.168.0.0 mask 255.255.248.0 192.168.25.9

      Т.е указать шлюзом L2TP нужно адрес L2TP, как это сделать в pFsense неясно

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

        А явное правило fw , к-ое выше всех стоит, на LAN pf есть ?
        Одного только NAT-а не хватит.

        1 Reply Last reply Reply Quote 0
        • P
          pigbrother
          last edited by

          Спасибо, забыл про правила.
          Создал 2 правила:

          Для L2TP:

          IPv4 * * * * * * none

          На LAN:

          IPv4 * LAN net * 192.168.0.0/21 * * none

          Включил логгинг

          В логе появились разрешенные пакеты. Однако пинги\ресурсы с той стороны недоступны.
          С LAN в pf не пингуется и шлюз удаленной сети.

          Поднимал соединение на Windows. Работало только после добавление вручную вот такого маршрута
          route add 192.168.0.0 mask 255.255.248.0 192.168.25.9, т.е. IP самого интерфейса.

          Т.е указать шлюзом L2TP нужно адрес L2TP, как это сделать в pFsense неясно

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

            Можно ли в правиле fw на LAN в кач-ве gw указать что-то типа l2tp gw\address ?

            P.s. Как вариант выдавать на Керио при подкл. по л2тп постоянный IP и через него уже рисовать правила.
            И еще , а Керио не блочит ли пакеты ? Посмотрите логи на нем.

            Я бы еще откл. NAT в правиле на pf (т.е. поставил галку на NO NAT), для того чтобы пакеты в 192.168.0.0/21 приходили от имени  10.0.2.0/24,
            а не от вирт. л2тп-интерфейса.

            И да, в удаленной сети шлюзом на всех машинах указан адрес Керио ? Есть ли на той стороне на раб. станциях fw\антивирусы ? Откл. их на время.

            1 Reply Last reply Reply Quote 0
            • P
              pigbrother
              last edited by

              Я бы еще откл. NAT в правиле на pf (т.е. поставил галку на NO NAT), для того чтобы пакеты в 192.168.0.0/21 приходили от имени  10.0.2.0/24,
              а не от вирт. л2тп-интерфейса.

              No NAT не помог.

              Помогло это:
              Можно ли в правиле fw на LAN в кач-ве gw указать что-то типа l2tp gw\address ?

              В правиле в
              Advanced features->Gateway

              указал шлюз L2TP

              И все заработало. Спасибо.

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

                Рад что получилось. Пригодится многим  8)

                No NAT не помог.

                Эээ, тут не то чтобы помощь, а в объективности мониторинга кто\что делал из сети 10.х в сети 192.168.х
                Иначе в логах будет будет светиться только один адрес - адрес вирт. интерфейса. Как-то так.

                1 Reply Last reply Reply Quote 0
                • P
                  pigbrother
                  last edited by

                  @werter:

                  Рад что получилось. Пригодится многим  8)

                  No NAT не помог.

                  Эээ, тут не то чтобы помощь, а в объективности мониторинга кто\что делал из сети 10.х в сети 192.168.х
                  Иначе в логах будет будет светиться только один адрес - адрес вирт. интерфейса. Как-то так.

                  Недостатки работы через NAT известны,, но, увы, с No NAT оно работать не хочет.

                  Любопытно, сеть 192.168.0.0/21 из моей LAN 10.0.2.0/24 - доступна. А пинга в pfSense с интерфейса LAN - нет.

                  Зато тема получает продолжение. Есть филиал 10.0.3.0/24 (Микротик), подключенный по OVPN в офис 10.0.2.0/24 (pfSense). Сети взаимно доступны.
                  Офис, как писал выше подключен к тому самому Керио 192.168.0.0/21 (NAT поверх L2TP)

                  Задача - подключить филиал 10.0.3.0/24 к тому самому Керио 192.168.0.0/21 через установленный NAT поверх L2TP.

                  Создал для начала:

                  NAT

                  L2TP  10.0.3.0/24 * 192.168.0.0/21 * L2TP address * NO

                  LAN

                  IPv4 * 10.0.3.0/24 * 192.168.0.0/21 * L2TPGW none

                  Но что-то явно сделано не так.

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

                    LAN

                    IPv4 *    10.0.3.0/24    *    192.168.0.0/21    *    L2TPGW    none

                    А оно разве на LAN к вам приходит? Не на др. ли интерфейс (l2tp) ?

                    2. Исп-те команду tracert из 10.0.3.0/24 до 192.168.0.0/21, чтобы посмотреть где затык.
                    И всегда ее исп-те в таких случаях:)

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

                      @pigbrother:

                      Любопытно, сеть 192.168.0.0/21 из моей LAN 10.0.2.0/24 - доступна. А пинга в pfSense с интерфейса LAN - нет.

                      Потому что из LAN пинги идут через PBR, а с самого pfSense вникуда, т. к. нет маршрута в сеть 192.168.0.0/21? Сделайте статический маршрут через шлюз L2TP и уберите PBR.

                      Зато тема получает продолжение. Есть филиал 10.0.3.0/24 (Микротик), подключенный по OVPN в офис 10.0.2.0/24 (pfSense). Сети взаимно доступны.
                      Офис, как писал выше подключен к тому самому Керио 192.168.0.0/21 (NAT поверх L2TP)

                      Задача - подключить филиал 10.0.3.0/24 к тому самому Керио 192.168.0.0/21 через установленный NAT поверх L2TP.

                      Создал для начала:

                      NAT

                      L2TP  10.0.3.0/24 * 192.168.0.0/21 * L2TP address * NO

                      LAN

                      IPv4 * 10.0.3.0/24 * 192.168.0.0/21 * L2TPGW none

                      Но что-то явно сделано не так.

                      А Микротик знает, что 192.168.0.0/21 находится за OpenVPN сервером?

                      1 Reply Last reply Reply Quote 0
                      • P
                        pigbrother
                        last edited by

                        Потому что из LAN пинги идут через PBR, а с самого pfSense вникуда, т. к. нет маршрута в сеть 192.168.0.0/21? Сделайте статический маршрут через шлюз L2TP и уберите PBR.

                        На pf добавил маршрут

                        192.168.0.0/21 L2TPGW - 192.168.25.1 L2TP

                        PBR для 10.0.2.0/24 убирать не стал, без него 10.0.2.0/24 теряет связь с 192.168.0.0/21.
                        Или имелось в виду убрать PBR для 10.0.3.0/24? Попробую завтра,  это правило на LAN мне кажется лишним.

                        А Микротик знает, что 192.168.0.0/21 находится за OpenVPN сервером?

                        На Микротик и ранее было добавлено:

                        Route

                        dst-address=192.168.0.0/21 gateway=10.11.12.1
                                gateway-status=10.11.12.1 reachable via  ovpn-out1 distance=20 scope=10
                                target-scope=10
                        NAT

                        chain=srcnat action=masquerade dst-address=192.168.0.0/21
                              out-interface=ovpn-out1 log=no

                        10.11.12.1 - серверный конец OVPN-туннеля на стороне pfSense , без его явного указания Микротики отказываются принимать маршруты.

                        Но без статического маршрута на pfSense в 192.168.0.0/21 не работало.

                        Заработало, пока оставил так.
                        Вероятно - осталось что-то лишнее

                        P.S.
                        Маршрут добавил бы и раньше, но несколько обескуражило

                        Do not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.

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

                          Тут по идее все должно работать без PBR, хотя, что там думает по этому поводу Kerio, сказать трудно. PBR непосредственно выводит пакет на L2 (if_output). То, что вы делали в Windows (route add 192.168.0.0 mask 255.255.248.0 192.168.25.9) - это on-link route, который говорит системе, что 192.168.0.0/21 находится в одном L2 сегменте с ее интерфейсом 192.168.25.9, т. е. то же самое. С другой стороны, L2TP между двумя pfSense работает как через gateway route (192.168.25.1), так и через on-link route (route add 192.168.0.0/21 -iface l2tp2).

                          1 Reply Last reply Reply Quote 0
                          • P
                            pigbrother
                            last edited by

                            Спасибо всем ответившим.

                            Остались мелкие шероховатости. При трассировке адреса за Керио из сети за Микротиком получаю следующее:

                            Трассировка маршрута к if-you-see-this-then-your-dns-resolver-is-wrong.provider_name.com [192.168.0.177]
                            с максимальным числом прыжков 30:

                            1    <1 мс    <1 мс    <1 мс  10.0.3.111
                              2    2 ms    4 ms    2 ms  a6850-r9-l2-s6.provider_name.com [10.11.12.1]
                              3    8 ms    8 ms    38 ms  if-you-see-this-then-your-dns-resolver-is-wrong.
                            provider_name.com [192.168.25.1]
                              4    8 ms    8 ms    8 ms  if-you-see-this-then-your-dns-resolver-is-wrong.
                            provider_name.com [192.168.0.177]

                            Трассировка завершена.

                            Хотя из за нежелания админа  Керио добавить маршруты в мои сети сделать  Site-to-site VPN полноценно  не получилось, хотел бы переименовать тему как Решено, но к своему стыду, не знаю как это сделать.

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

                              2 pigbrother
                              Все же обдумайте предложение встретить "повелителя" Керио вечером после работы эээ… не с букетом цветов  ::)

                              "Добрым словом и кольтом можно добиться гораздо большего, чем только добрым словом" (Аль Капоне)

                              1 Reply Last reply Reply Quote 0
                              • P
                                pigbrother
                                last edited by

                                Про отсутствие кольта жалел не раз. :)

                                Встретиться проблематично - он в другом городе. Да и мое подключение к ним - подчиненное, мы выступаем в роли филиала.
                                Удалось избавится от клиента Керио ВПН на каждом рабочем месте - уже здорово. Ну и них нет доступа в наши сети - так даже спокойнее.

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pigbrother
                                  last edited by

                                  Обратил внимание, что L2TP-интерфейс при создании оказался привязан к LAN, а не WAN.
                                  На что эта привязка может\должна влиять?

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

                                    Адрес интерфейса привязки выступает в качестве src ip пакетов, исходящих от L2TP клиента (set l2tp self ipaddr в mpd.conf), если другое явно не указано в поле "Local IP" настроек PPP. Практически все равно, только, если L2TP привязан к LAN и в Local IP пусто, то к исходящим пакетам применяется Outbound NAT.

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pigbrother
                                      last edited by

                                      Практически все равно, только, если L2TP привязан к LAN и в Local IP пусто, то к исходящим пакетам применяется Outbound NAT.

                                      Все понятно, спасибо.
                                      Однако при попытке отцепить L2TP от LAN и привязать к одному из WAN получил crash системы с  циклической перезагрузкой pfSense на этапе поднятия WAN-интерфейсов.
                                      Вспоминаю, что подобное было еще на 2.0.х, правда с PPTP.

                                      Теперь в GUI болтается неудаляемое штатно сообщение о крахе системы, что, похоже, тоже давняя болезнь:
                                      https://redmine.pfsense.com/issues/3486
                                      Пришлось чистить /var/crash вручную.

                                      Незагружаемую систему восстановил из single user mode. Удобно - не нужно загружаться с CD\Flash, используются автобэкапы, которые pfSense делает по умолчанию каждый час

                                      Процедура простая, если кому-то интересно - могу выложить, можно отдельной темой.

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

                                        Процедура простая, если кому-то интересно - могу выложить, можно отдельной темой.

                                        Оч. бы хотелось. И с картинками  ;)

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          pigbrother
                                          last edited by

                                          Картинкам там взяться неоткуда  :)

                                          Раньше использовал такой способ:
                                          https://forum.pfsense.org/index.php?topic=93943.msg521319#msg521319

                                          Показалось, что можно сделать это проще.

                                          В начале  загрузки pfSense есть меню, где следуют выбрать single user mode, обычно это клавиша s, в старых\новых релизах может быть другой.

                                          1. Предлагается выбрать shell. Нажимаем Enter для выбора /bin/sh

                                          2. В появившемся приглашении набираем /sbin/mount -o rw / иначе файловая система останется read-only, а мы ведь собираемся манипулировать файлами. Если монтирование прошло удачно - переходим к п.4, если нет - см. п.3

                                          3. Mount может ругнуться, что файловая система "is not clear" и предложит запустить fsck. Соглашаемся, если fsck не запустится сам - стартуем его вручную - /sbin/fsck. Соглашаемся на предложения fsck исправить ошибки.
                                          Вновь запускаем /sbin/mount -o rw /

                                          4. Переходим в каталог, где лежит "плохой" конфиг:
                                          cd cf/conf

                                          5. Сохраняем его на всякий случай:
                                          cp config.xml config.bad

                                          6. Удаляем "плохой" конфиг:
                                          rm config.xml

                                          7. Переходим в папку автобэкапов:
                                          cd /conf/backup

                                          8. смотрим содержание папки автобэкапов:
                                          ls
                                          Видим список конфигов вида config-14xxxxxxx.xml. Цифры - дата и время создания бэкапов в Unix-стиле. Более свежие файлы идут  в конце.

                                          9. Выбираем и копируем  с переименованием конфиг из папки бэкапов в рабочую папку:
                                          cp config-14xxxxxxx.xml  /cf/conf/config.xml

                                          10. Перегружаемся:
                                          /sbin/reboot

                                          Если файловая система была сильно повреждена, восстановление config.xml таким, да и любым другим способом может не помочь.

                                          1 Reply Last reply Reply Quote 0
                                          • P
                                            pigbrother
                                            last edited by

                                            @rubic:

                                            Адрес интерфейса привязки выступает в качестве src ip пакетов, исходящих от L2TP клиента (set l2tp self ipaddr в mpd.conf), если другое явно не указано в поле "Local IP" настроек PPP. Практически все равно, только, если L2TP привязан к LAN и в Local IP пусто, то к исходящим пакетам применяется Outbound NAT.

                                            То есть если Local IP не заполнено то src IP для пакетов, уходящих в Outbound NAT будет IP LAN-интерфейса pfSense?

                                            И все же - если привязка PPP к WAN не является нарушением, почему  pfSense (и 2.0 и 2.1 и 2.2) падает при привязке PPP к WAN? Причем падает неприятно, с циклической перезагрузкой на поднятии этого привязанного к WAN PPP?

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