IPSec в транспортном шифровать конкретный протокол
-
@werter Если изменения внесены в inc файл , то все это действует
inc файл перезаписывается заново только при обновлении системы
А ТС именно так и сделал
Все это написано у меня ранее
Konstanti a day ago
@yos Дописывать что в конфиг Вы хотите ? Чтобы формировалась строка left/rightsubnet = ip адрес [gre] ? - надо менять inc файл
Иначе то что прописываете ручками в ipsec.conf ,после перезагрузки или изменения настроек будет удалено . -
@konstanti а можете показать реальный пример, какой трафик на каком интерфейсе нужно заворачивать в ipsec или gre туннель?
У меня без заворачиваний в туннель заработал gre over ipsec на pf 2.4.4, обе подсети между собой гоняют трафик нормально, а вот на втором где 2.4.3 - почему то pf сам ходит во вторую подсеть, а подсеть за ним не ходит. -
@yos Доброго дня
Не совсем понял написанное .
Можно больше деталей ?
Сформулируйте пож задачу , которая стоит перед Вами
В туннель попадает именно тот трафик , который Вы явно сами и укажите в настройке правил , к примеру , интерфейса LAN.
Цитата
Что такое Policy-based Routing (PBR)
Policy-based routing (PBR) перевод данного словосочетания несет смысл такого характера, как маршрутизация на основе определенных политик (правил, условий), которые являются относительно гибкими и устанавливаются Администратором. Другими словами это технология предоставляет условия гибкой маршрутизации (если смотреть на технологию с первоочередной ее задачи), по источнику или назначению пакета.И еще - самое важное !!!!
Очередность правил очень важна . Срабатывает самое первое правило , подходящее под определенное условие
Вот пример
В этом примере , весь трафик для сайта Московского правительства идет через шлюз по умолчанию .
А вот в следующем правиле весь трафик от хоста 192.168.1.96 попадает в gre туннель.
Т. е. если трафик от 96 будет идти к PGU_MOS , то он пойдет через wan
а весь остальной пойдет через gre -
@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'е у меня начинает работать, что-то нужно с его стороны крутить.
- Сделал floating правило
-
@yos Все дело в том , что Вы невнимательно читали , что я писал
Повторяю
У pfsense есть один нюанс при работе GRE over IPSEC из-за которого все идет кувырком . Возможно , дело в нем . Т.е. при загрузке сначала инициализируется gre а потом уже ipsec . Из-за этой очередности возникает проблема в работе . Т.е. , по уму, должно быть так, загрузился strongswan , поднялся ipsec в транспортном режиме , а потом уже инициализируется GRE.Из-за этого пакеты GRE не попадают в IPSEC туннель
Найдите это сообщение чуть выше , там прописан путь решения проблемы
Если не сложно покажите пож , вывод команды ping и tcpdump на wan интерфейсе при наличии проблемы . -
@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 641.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 -
@yos Именно эта проблема и есть
пакеты для gre не попадают в ipsec
Отключите gre интерфейс , сохранитесь
убедитесь , что ifconfig его не показывает
перезагрузитесь
убедитесь , что ipsec поднялся
включите gre интрефейс и проверьте , что все работает -
@konstanti да, работает. Но это не дело, каждый раз ручками его подымать перезагрушая шлюз, за которым 24/7 работает офис(
-
@yos А зачем лезть туда , где все работает ? Один раз настроил и в путь
у меня PF работает месяцами и нет проблем
Это особенность PF , и ее надо или принять или нет
Если хотите что-то менять , то
1 или разбираться с процессом загрузки PF
2 или уходить от GRE over IPSEC в сторону OPenVPN или VTI -
@konstanti это понятно что один раз сделал и работает, но в текущем случаи - до первой перезагрузки, которая может оказаться незапланированной, даже в тот момент когда ты в отпуске - после этого GRE over IPsec "ломается" и все не очень хорошо может оказаться для тебя же.
Я бы не сказал что это особенность, а скорее "это фича а не баг" :)
Здесь из выходов переходить на чисто туннельный режим IPsec/VTI, или переходить с pfsense на ту же чистую freebsd. Ну или заморочиться и настроить загрузку самого pfsense, чтоб он загружал все именно так, как нужно. Но и тут камни - когда нужен еще один туннель поднять - без перезагрузки шлюза ты его нормально не подымешь.
@konstanti и еще раз спасибо за потраченное время в попытках мне помочь! И это не зря - я разобрался в некоторых вещах и узнал немного нового. -
@yos Даже стало интересно , как он грузится
тут стало все понятно
Он инициализирует в начале процесса загрузки все интерфейсы в кучу - и физические и виртуальные
И никто не думал в тот момент , что GRE потом может быть инкапсулирован в IPSEC . Если будет возможность и время , я попробую с этим разобраться
