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



  • Не сталкивался ли кто с подобной задачей?

    Предлагаемые Kerio Control возможности по созданию VPN-сервера:
    https://habrahabr.ru/post/192246



  • Доброе.
    В чем загвоздка ?



  • Вероятно - нет загвоздки, за исключением возможной несовместимости.
    Со стороны pfSense просто поднять Interfaces->PPPs->L2TP.
    Админ со стороны Kerio поднимет сервер - проверю.



  • @pigbrother:

    Админ со стороны Kerio поднимет сервер - проверю.

    Обратите его в нашу веру :)



  • Обратите его в нашу веру

    Пытался. Попыток пока не оставил. :)

    В свете заданного вопроса - если я настрою коннект к нему через L2TP, свою сеть я через NAT в их сеть направлю.
    А хочется прозрачного site-to-site



  • @pigbrother:

    Обратите его в нашу веру

    Пытался. Попыток пока не оставил. :)

    В свете заданного вопроса - если я настрою коннект к нему через L2TP, свою сеть я через NAT в их сеть направлю.
    А хочется прозрачного site-to-site

    Ну это будет зависеть от админа Kerio, владеет ли он маршрутизацией.
    Отключить NAT и прописать-получить удаленные сети на pfSense обычно не проблема



  • Не пойму, чего не хватает.
    Удаленная сеть 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 неясно



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



  • Спасибо, забыл про правила.
    Создал 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 неясно



  • Можно ли в правиле 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\антивирусы ? Откл. их на время.



  • Я бы еще откл. 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

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



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

    No NAT не помог.

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



  • @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

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



    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, чтобы посмотреть где затык.
    И всегда ее исп-те в таких случаях:)



  • @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 сервером?



  • Потому что из 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.



  • Тут по идее все должно работать без 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).



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

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

    Трассировка маршрута к 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 полноценно  не получилось, хотел бы переименовать тему как Решено, но к своему стыду, не знаю как это сделать.



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

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



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

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



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



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



  • Практически все равно, только, если 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 делает по умолчанию каждый час

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



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

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



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

    Раньше использовал такой способ:
    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 таким, да и любым другим способом может не помочь.



  • @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?



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



  • PPPOE

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



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



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



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



  • 2 pigbrother
    Огромное спасибо за инс-цию  ::)