IPSec в транспортном шифровать конкретный протокол

Konstanti

@yos Дописывать что в конфиг Вы хотите ? Чтобы формировалась строка left/rightsubnet = ip адрес [gre] ? - надо менять inc файл
Иначе то что прописываете ручками в ipsec.conf ,после перезагрузки или изменения настроек будет удалено .

У меня все прекрасно работает без модификаций этих файлов
Я Вам давал примеры , как это настроено со стороны strongswan freebsd . Там да , там прописано как в документации
а в документации прописано так
Configuration

As mentioned above, a host-to-host IPsec connection in transport mode can be used. The traffic selectors may even be limited to just the GRE protocol (local|remote_ts=dynamic[gre] in swanctl.conf or left|rightsubnet=%dynamic[gre] in ipsec.conf).

а в настройках PF ничего не менял . ( в inc файлах)

Yos

@konstanti в идеале меня бы устроило чтоб он сам дописывал [gre], не зря же так в документации прописано. Как я понял, в pf это не предусмотрено, и не понимаю почему именно так в нем сделали... В итоге pf не полноценно совместим с racoon на второй стороне. Я не могу на второй стороне все заворачивать в ipsec, так как отваливаются все остальные сервисы которые не должны ходить через ipsec.
Проверил на микротике - подымается нормально, и не имеет значения только gre или всё заворачивать - с микротиком ipsec подымается. Похоже и strongswan'у у вас с прописаным [gre] без разницы что с обратной стороны этого нет.
Еще вот заметил что перестают проходить icmp ping'и на вшений ИП pf'а, если они идут из ИП с которым необходимо подымать ipsec, и без разницы поднят он или нет - пинги не проходят, но http и ssh на pf работают без проблем. Если дописать [gre] - пинги тоже начинают ходить.

Konstanti

@yos OK, попробую помочь Вам. Только чуть позже. С php дружите? А так, я бы Вам посоветовал развернуть ВМ с freebsd. И поэкспериментировать с strongswan+GRE.

Yos

@konstanti Спасибо! С php дружу на начальном уровне, просматриваю сейчас vpn.inc, но пока мало времени чтоб разобрать как оно работает. С strongswan буду экспериментировать, скорее всего перейду на него с racoon, так как racoon входящий в ipsec-tools не поддерживает ikev2

Konstanti

@yos файл верный смотрите. Ищите там текст transport. В этом блоке формируются строки leftsubnet и rightsubnet. Вот к этим строкам надо дописывать $переменная. "[gre]". Я не у компа, пишу по памяти. Сегодня только думал об этом. Но помните о том, что измение Inc файла работает до любого обновления pf. Попробуйте так изменить только в этом блоке следующие строчки
$leftsubnet_spec[] = $tmpsubnet."[gre]";
$rightsubnet_spec[] = $right_spec."[gre]";
Файл сохраняете. Идёте потом в настройки IPSeC, заходите, к примеру, в фазу 1, ничего не делаете, жмёте кнопку сохранить и выходите. И проверяйте файл ipsec.conf

Yos

@konstanti получилось! Спасибо за помощь!

werter

Добрый.

Файл сохраняете. Идёте потом в настройки IPSeC, заходите, к примеру, в фазу 1, ничего не делаете, жмёте кнопку сохранить и выходите. И проверяйте файл ipsec.conf

Попробуйте после внести любые изменения в настройках ipsec через веб-гуи. И проверить файл ipsec.conf, сохранились ли предыдущие внесенные руками правки. Всякое бывает, знаете ли.

Konstanti

@werter Если изменения внесены в inc файл , то все это действует
inc файл перезаписывается заново только при обновлении системы
А ТС именно так и сделал
Все это написано у меня ранее
Konstanti a day ago
@yos Дописывать что в конфиг Вы хотите ? Чтобы формировалась строка left/rightsubnet = ip адрес [gre] ? - надо менять inc файл
Иначе то что прописываете ручками в ipsec.conf ,после перезагрузки или изменения настроек будет удалено .

Yos

@konstanti а можете показать реальный пример, какой трафик на каком интерфейсе нужно заворачивать в ipsec или gre туннель?
У меня без заворачиваний в туннель заработал gre over ipsec на pf 2.4.4, обе подсети между собой гоняют трафик нормально, а вот на втором где 2.4.3 - почему то pf сам ходит во вторую подсеть, а подсеть за ним не ходит.

Konstanti

@yos Доброго дня
Не совсем понял написанное .
Можно больше деталей ?
Сформулируйте пож задачу , которая стоит перед Вами
В туннель попадает именно тот трафик , который Вы явно сами и укажите в настройке правил , к примеру , интерфейса LAN.
Цитата
Что такое Policy-based Routing (PBR)
Policy-based routing (PBR) перевод данного словосочетания несет смысл такого характера, как маршрутизация на основе определенных политик (правил, условий), которые являются относительно гибкими и устанавливаются Администратором. Другими словами это технология предоставляет условия гибкой маршрутизации (если смотреть на технологию с первоочередной ее задачи), по источнику или назначению пакета.

И еще - самое важное !!!!
Очередность правил очень важна . Срабатывает самое первое правило , подходящее под определенное условие
Вот пример
0_1542455345303_65c7f94d-6402-4252-a801-1bff596af346-image.png

В этом примере , весь трафик для сайта Московского правительства идет через шлюз по умолчанию .
А вот в следующем правиле весь трафик от хоста 192.168.1.96 попадает в gre туннель.
Т. е. если трафик от 96 будет идти к PGU_MOS , то он пойдет через wan
а весь остальной пойдет через gre

Yos

@konstanti извиняюсь что не часто могу отвечать - не могу сразу применять настройки и проверять из-за нехватки времени.
Что сейчас у меня есть: pf и FreeBSD с racoon, на pf я допилил inc и теперь всегда в транспортном режиме получаю:
$leftsubnet_spec[] = $tmpsubnet."[gre]";
$rightsubnet_spec[] = $right_spec."[gre]";
Из-за этого подымается IPsec с FreeBSD, но с обеих сторон не могу даже пропинговать IP-адреса туннелей. Отключаю IPsec - отлично бегает трафик между обеими подсетями.
Юзаю "pfctl -d" - все работает, тот же график в вебке показывает загрузку как IPsec так и GRE интерфейсов. Обратно включаю "pfctl -e" - только загрузка IPsec интерфейса.
При этом:

Сделал floating правило
Сделал правило на LAN интерфейсе в сторону второй подсети, куда мне нужно ходить
Пробовал даже поменять правило на подсеть тунелей, но IP второго туннеля не пингуется
пробовал по очереди тушить-подымать IPsec и GRE а разных последовательностях - не помогает.
Судя по тому, что после отключения файрволла на pf'е у меня начинает работать, что-то нужно с его стороны крутить.

Konstanti

@yos Все дело в том , что Вы невнимательно читали , что я писал
Повторяю
У pfsense есть один нюанс при работе GRE over IPSEC из-за которого все идет кувырком . Возможно , дело в нем . Т.е. при загрузке сначала инициализируется gre а потом уже ipsec . Из-за этой очередности возникает проблема в работе . Т.е. , по уму, должно быть так, загрузился strongswan , поднялся ipsec в транспортном режиме , а потом уже инициализируется GRE.

Из-за этого пакеты GRE не попадают в IPSEC туннель
Найдите это сообщение чуть выше , там прописан путь решения проблемы
Если не сложно покажите пож , вывод команды ping и tcpdump на wan интерфейсе при наличии проблемы .

Yos

@konstanti я делал как выше Вы говорили - в веб-интерфейсе снимал/ставил галочку на интерфейсе, пробовал через консоль положить/поднять gre при поднятом ipsec - не помогает. Когда я выключаю файрволл на pf'е, у меня начинает нормально работать gre over ipsec, я об этом выше писал.

Вот tcpdump при наличии проблемы:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
1542964703.798513 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 66: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 32: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 4182, seq 28170, length 8
1542964703.979736 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 122: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 88: 172.16.0.10 > 10.60.60.1: ICMP echo reply, id 46161, seq 47769, length 64
1542964704.323506 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 66: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 32: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 4182, seq 28171, length 8
1542964704.476866 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 122: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 88: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 29035, seq 70, length 64
1542964704.809092 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 98: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 64: 172.16.0.10 > 10.0.1.11: ICMP echo request, id 1, seq 12976, length 40
1542964704.848498 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 66: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 32: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 4182, seq 28172, length 8
1542964704.997343 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 122: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 88: 172.16.0.10 > 10.60.60.1: ICMP echo reply, id 46161, seq 47770, length 64
1542964705.370500 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 66: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 32: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 4182, seq 28173, length 8
1542964705.483420 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 122: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 88: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 29035, seq 71, length 64
1542964705.900504 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 66: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 32: 10.60.60.2 > 10.60.60.1: ICMP echo request, id 4182, seq 28174, length 8
1542964706.052525 fc:aa:14:2a:91:34 > 3c:8a:b0:33:e0:2e, ethertype IPv4 (0x0800), length 122: 2.2.2.2 > 1.1.1.1: GREv0, proto IPv4 (0x0800), length 88: 172.16.0.10 > 10.60.60.1: ICMP echo reply, id 46161, seq 47771, length 64

1.1.1.1 - FreeBSD внешний IP
2.2.2.2 - pfSense внешний IP
10.60.60.1 - GRE IP со стороны FreeBSD
10.60.60.2 - GRE IP со стороны pfSense
10.0.1.0/24 - сеть за FreeBSD
172.16.0.0/24 - сеть за pfSense

На pf'е когда отправляю пинги в сторону фряхи, получаю:

ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied

Konstanti

@yos Именно эта проблема и есть
пакеты для gre не попадают в ipsec
Отключите gre интерфейс , сохранитесь
убедитесь , что ifconfig его не показывает
перезагрузитесь
убедитесь , что ipsec поднялся
включите gre интрефейс и проверьте , что все работает

Yos

@konstanti да, работает. Но это не дело, каждый раз ручками его подымать перезагрушая шлюз, за которым 24/7 работает офис(

Konstanti

@yos А зачем лезть туда , где все работает ? Один раз настроил и в путь
у меня PF работает месяцами и нет проблем
Это особенность PF , и ее надо или принять или нет
Если хотите что-то менять , то
1 или разбираться с процессом загрузки PF
2 или уходить от GRE over IPSEC в сторону OPenVPN или VTI

Yos

@konstanti это понятно что один раз сделал и работает, но в текущем случаи - до первой перезагрузки, которая может оказаться незапланированной, даже в тот момент когда ты в отпуске - после этого GRE over IPsec "ломается" и все не очень хорошо может оказаться для тебя же.
Я бы не сказал что это особенность, а скорее "это фича а не баг" :)
Здесь из выходов переходить на чисто туннельный режим IPsec/VTI, или переходить с pfsense на ту же чистую freebsd. Ну или заморочиться и настроить загрузку самого pfsense, чтоб он загружал все именно так, как нужно. Но и тут камни - когда нужен еще один туннель поднять - без перезагрузки шлюза ты его нормально не подымешь.
@konstanti и еще раз спасибо за потраченное время в попытках мне помочь! И это не зря - я разобрался в некоторых вещах и узнал немного нового.

Konstanti

@yos Даже стало интересно , как он грузится
тут стало все понятно
Он инициализирует в начале процесса загрузки все интерфейсы в кучу - и физические и виртуальные
И никто не думал в тот момент , что GRE потом может быть инкапсулирован в IPSEC . Если будет возможность и время , я попробую с этим разобраться