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

Yos

@Konstanti не совсем понял в Вас, или Вы меня.
Мне не нужен IPSec туннель, мне нужно чтоб он между двумя узлами только шифровал трафик. Вот сейчас пытаюсь настроить GRE over IPSec, что означает GRE туннель внутри IPSec.
У меня даже не проходит первая фаза, на стороне FreeBSD я указал шифровать весь трафик, но никак.

ERROR: notification NO-PROPOSAL-CHOSEN received in unencrypted informational exchange

Konstanti

@yos Вы спросили , как это сделать в PF , я попытался ответь
у меня так работает связка PF-Freebsd
Настройки со стороны Freebsd я показал
Используется связка Strongswan + gre
Security Associations (1 up, 0 connecting):
es_ru_fr_ecdsa[29]: ESTABLISHED 3 hours ago, XXX.XXX.XXX.XXX[]...XXX.XXX.XXX.XXX[]
es_ru_fr_ecdsa[29]: IKEv2 SPIs: bf7c92c0a032be91_i eb918575d93185a1_r*, public key reauthentication in 4 hours
es_ru_fr_ecdsa[29]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
es_ru_fr_ecdsa{64}: INSTALLED, TRANSPORT, reqid 16, ESP SPIs: c31fb516_i c9623214_o
es_ru_fr_ecdsa{64}: AES_CBC_256/HMAC_SHA2_256_128, 1021595 bytes_i (6962 pkts, 10906s ago), 2712376 bytes_o (6718 pkts, 1s ago), rekeying in 38 minutes
es_ru_fr_ecdsa{64}: XXX.XXX.XXX./32[gre] === XXX.XXX.XXX.XXX/32[gre]
root@fr:/usr/home/konstanti #

ifconfig
gre0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
options=80000<LINKSTATE>
tunnel inet XXX.XXX.XXX.XXX --> XXX.XXX.XXX.XXX
inet 10.10.200.2 --> 10.10.200.1 netmask 0xffffff00
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

а потом уже средствами Packet Filter я пихаю в туннель тот трафик , который мне надо шифровать
Со стороны PF зеркальные настройки

1 фаза не проходит - покажите пож настройки PF первой и второй фазы
ошибка означает , что ike proposal не найден
Предположу, что dh_group не бьется - у Вас 2 , у PF по умолчанию 14
если исходить из ваших настроек
то сделать на стороне PF надо так
фаза 1
0_1540898769875_960b6e29-b415-44d8-93ea-f3a63089a9f5-image.png
фаза 2
0_1540898860429_fbcd9989-62f4-4af2-ace4-86e50c7efffc-image.png

Обратите внимание , что все работает в транспортном режиме

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'е у меня начинает работать, что-то нужно с его стороны крутить.