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

pigbrother

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

rubic

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

pigbrother

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

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

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

werter

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

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

pigbrother

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

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

pigbrother

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

rubic

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

pigbrother

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

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

werter

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

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

pigbrother

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

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

pigbrother

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

rubic

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

pigbrother

PPPOE

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

rubic

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

pigbrother

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

rubic

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

werter

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