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



  • Здравствуйте!
    Мне необходимо с помощью IPSec в транспортном режиме шифровать только конкретный трафик, а не весь. Облазил все настройки - так и не нашел как это можно задать.
    Как мне на pfsense это можно настроить?

    К примеру, на обычном FreeBSD маршрутизаторе шифровать только GRE трафик (47-ой протокол) я задаю следующим образом:

    ipsec.conf (указываем не all а gre)

    spdadd 1.1.1.1/32 2.2.2.2/32 gre -P out ipsec esp/transport/1.1.1.1-2.2.2.2/require;
    spdadd 2.2.2.2/32 1.1.1.1/32 gre -P in ipsec esp/transport/2.2.2.2-1.1.1.1/require;
    

    racoon.conf (во второй фазе номер gre - 47)

    # --- Phase 1
    remote 2.2.2.2
    {
            my_identifier address 1.1.1.1;
            peers_identifier address 2.2.2.2;
            exchange_mode main;
            doi ipsec_doi;
            situation identity_only;
            passive off;
            proposal_check obey;
            generate_policy off;
            nonce_size 16;
            initial_contact on;
            lifetime time 24 hour;
    
            proposal {
                    encryption_algorithm aes 256;
                    hash_algorithm sha256;
                    authentication_method pre_shared_key;
                    dh_group 2;
                    lifetime time 1 hour;
            }
    }
    
    # --- Phase 2
    sainfo  address 1.1.1.1/32 47 address 2.2.2.2/32 47
    {
            encryption_algorithm aes 256;
            authentication_algorithm hmac_sha256;
            compression_algorithm deflate;
            pfs_group 2;
            lifetime time 1 hour;
    }
    
    


  • @yos Добрый день
    тут тот же принцип
    создаете IPSEC туннель в транспортном режиме
    дальше создаете GRE интерфейс и активируете его
    получаете GRE over IPSEC
    и дальше уже с помощью PBR в GRE заворачиваете тот трафик , который хотите маршрутизировать и шифровать
    Просто Вы используете Racoon , а PFSense использует Strongswan
    Если стоит версия 2.4.4 - то уже можно использовать VTI
    вот так это выглядит со стороны ( для Freebsd )
    0_1540896452425_ad19d6b5-c714-49df-8115-bd5e0416526c-image.png

    Активируется ipsec туннель , а потом поверх него GRE
    а вот так со стороны strongswan
    0_1540896624991_cb8caa6c-a120-4fc1-a513-153573fcd45c-image.png



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

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


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

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



  • @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:
    0_1540899380044_01.jpg

    0_1540899390628_2.jpg

    0_1540899400065_3.jpg



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



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



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

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



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



  • @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 попадает в туннель и шифруется



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

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

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



  • @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 файлах)



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



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



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



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



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



  • Добрый.

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

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



  • @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) перевод данного словосочетания несет смысл такого характера, как маршрутизация на основе определенных политик (правил, условий), которые являются относительно гибкими и устанавливаются Администратором. Другими словами это технология предоставляет условия гибкой маршрутизации (если смотреть на технологию с первоочередной ее задачи), по источнику или назначению пакета.

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

    В этом примере , весь трафик для сайта Московского правительства идет через шлюз по умолчанию .
    А вот в следующем правиле весь трафик от хоста 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 интерфейса.
    При этом:

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


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


  • @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 . Если будет возможность и время , я попробую с этим разобраться