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

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

    Scheduled Pinned Locked Moved
    Russian
    4
    32
    9.6k
    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.
    • 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
                                  • R
                                    rubic
                                    last edited by

                                    Да, см. sockstat
                                    Не знаю, а какой тип WAN?

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

                                      PPPOE

                                      Сходная ошибка в багтрекере:
                                      https://redmine.pfsense.org/issues/4510

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

                                        Думаю, какая-то интерференция PPPoE и L2TP, т. к. в конечном итоге все делается через mpd. На IPoE проблем нет.

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

                                          Вероятно - да. в 2.3 mpd обещают обновить.
                                          Позволю себе еще один вопрос:
                                          Если, оставив привязку к LAN, в Local IP я укажу IP, валидный в удаленной сети с маской этой сети что мне это даст? Можно будет обойтись без Outbound NAT? Достаточно\нужно будет будет просто добавить маршрут в эту сеть?

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

                                            Это даст падение туннеля, ну как же так-то? Под src ip я имею ввиду не внутритуннельный трафик, а трафик устанавливающий туннель.

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