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

Yos

@konstanti с IPSec'ом столкнулся недавно, поэтому я еще плохо разбираюсь. Подружить MikroTik и FreeBSD получилось без особых трудностей, а вот с PF пока не понимаю.
У меня на FreeBSD стоит racoon, вот его логи когда включаю на PF IPSec (ip'ы изменил 1 - это FreeBSD, 2 - PF):

2018-10-30 11:30:31: INFO: respond new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]
2018-10-30 11:30:31: [2.2.2.2] ERROR: failed to get valid proposal.
2018-10-30 11:30:31: [2.2.2.2] ERROR: failed to pre-process ph1 packet (side: 1, status 1).
2018-10-30 11:30:31: [2.2.2.2] ERROR: phase1 negotiation failed.
2018-10-30 11:30:35: INFO: respond new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]
2018-10-30 11:30:35: [2.2.2.2] ERROR: failed to get valid proposal.
2018-10-30 11:30:35: [2.2.2.2] ERROR: failed to pre-process ph1 packet (side: 1, status 1).
2018-10-30 11:30:35: [2.2.2.2] ERROR: phase1 negotiation failed.
2018-10-30 11:30:39: INFO: ISAKMP-SA established 1.1.1.1[500]-2.2.2.2[500] spi:f7593bd7ccbfefd1:1f4479bff02a6086
2018-10-30 11:30:39: INFO: initiate new phase 2 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]
2018-10-30 11:30:39: INFO: IPsec-SA established: ESP/Transport 1.1.1.1[500]->2.2.2.2[500] spi=101460905(0x60c2ba9)
2018-10-30 11:30:39: INFO: IPsec-SA established: ESP/Transport 1.1.1.1[500]->2.2.2.2[500] spi=3459036283(0xce2cb47b)
2018-10-30 11:30:42: INFO: respond new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]
2018-10-30 11:30:42: [2.2.2.2] ERROR: failed to get valid proposal.
2018-10-30 11:30:42: [2.2.2.2] ERROR: failed to pre-process ph1 packet (side: 1, status 1).
2018-10-30 11:30:42: [2.2.2.2] ERROR: phase1 negotiation failed.

А вот такие настройки на стороне PF:

Konstanti

@yos Так-то бьется все
кроме одного
я с racoon не очень знаком , но
вижу , что у него предполагается сжатие
а в pf это по умолчанию отключено
попробуйте , или убрать сжатие из racoon
или включить эту опцию pf - ipsec- advanced settings

Yos

@konstanti можете показать как Вы со стороны pfsense заворачиваете GRE трафик в ipsec ?
Мне нужно чтобы GRE трафик в сторону фряхи был завернут в ipsec, а остальной в ее же сторону ходил голый.

Konstanti

@yos добрый вечер
Туннель поднят? Ip адрес GRE интерфейса на freebsd доступен?
Если все ок, то вот ссылка
https://forum.netgate.com/topic/137671/два-wan-два-lan-нужно-чтобы-каждый-lan-выходил-через-свой-wan

Принцип тот же самый, вы создаёте правило, согласно которого трафик идёт в GRE туннель и шифруется. А следом, правило, которое пускает трафик через шлюз по умолчанию.

Yos

@konstanti без ipsec'а у меня отлично подняты туннели и трафик между двумя подсетями ходит даже не заворачивая в GRE туннель через файрволл на pfsense - достаточно только прописать роуты на обеих маршрутизаторах.
А вот когда пытаюсь настроить ipsec в транспортном - тут начинается головоломка. Если я на стороне фряхи прописываю между ней и pfsense поддавать криптованию "any"(весь трафик), а не чисто gre, то между ними фазы устанавливаются, но подсети по gre перестают ходить (видимо не правильно настроил на стороне pfsense). В этом режиме достучаться к фряхе по другим протоколам - нельзя. Но мне же нужно криптовать только gre трафик между их внешними интерфейсами! А если пропишу на стороне фряхи криптовать только gre - они между собой не согласовываются и ipsec не подымается.
Не могу понять логику, как это устроено на pfsense. На том же mikrotik при настройке ipsec я ясно задаю что мне в транспортном нужно криптовать "только конкретно вот такой трафик", и сейчас так у меня уже работает несколько офисов...(

Konstanti

@yos said in IPSec в транспортном шифровать конкретный протокол:

по gre перестают ходит

У pfsense есть один нюанс при работе GRE over IPSEC из-за которого все идет кувырком . Возможно , дело в нем . Т.е. при загрузке сначала инициализируется gre а потом уже ipsec . Из-за этой очередности возникает проблема в работе . Т.е. , по уму, должно быть так, загрузился strongswan , поднялся ipsec в транспортном режиме , а потом уже инициализируется GRE.
Некоторые делают так ,в консоли по ssh набирают после загрузки
ifconfig gre0 down
ipsec restart
ipsec statusall ( проверяем , что ipsec поднялся)
ifconfig gre0 up
или просто в веб интерфейсе отключают gre интерфейс (cм рисунок)
0_1542230569464_900e31d6-d1ae-41b7-aec8-23ef51621319-image.png
отключаем галку - перегружаемся , проверяем ipsec , если все ок , включаем обратно галку , сохраняемся

Дальше я создаю правила ( где-то читал , что лучше floating) для разрешения прохождения трафика через gre туннель ( в обе стороны)
0_1542230730674_3e9483a0-0071-4d15-870f-6bf7f3d66691-image.png
проверяем , что вторая сторона туннеля доступна
0_1542231223576_2a66cc00-38b4-42ea-a855-f68ec3d6be86-image.png
убеждаемся , что трафик шифруется
[2.4.4-RELEASE][admin@ru.malgrat.org]/root: tcpdump -netti igb0 dst XXX.XXX.XXX.XXX
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:08:a2:0a:ff:72 > 00:90:1a:a3:be:e1, ethertype IPv4 (0x0800), length 170: XX.XXX.XX.XXX > XX.XX.XXX.XX: ESP(spi=0xc14c567b,seq=0x365f), length 136

и после всего этого создаю правила , которые загоняют тот трафик в туннель, который Вам нужен (lan интерфейс , см ссылку , что я дал выше)

0_1542230850316_9bf5c562-bfe7-4cae-823b-86f1de7706a7-image.png

В данном примере - весь трафик от 192.168.1.32/27 попадает в туннель и шифруется

Yos

@konstanti экспериментально я подружил их. На pf ручками в автоконфиг дописал какой именно трафик мне криптовать:

rightsubnet = 1.1.1.1[gre]
leftsubnet = 2.2.2.2[gre]

На стороне freebsd я так же указал gre вместо any, аналогично моему примеру в первом посте.
Проверил что действительно только gre заворачивается в ipsec, остальной трафик как и должен ходит мимо ipsec.
Как я понял из примеров в интернете, которые я находил, на strongswan так и нужно прописывать.
Остается понять как заставить pf дописывать это в конфиг.

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