Вложенные GRE тунели


  • Добрый день, Pfsense 2.4.5
    Возникла необходимость создать вложенный GRE тунель.
    В системных логах вижу повторяющуюся ошибку:

    gre1: if_output recursively called too many times(2) 
    

    Погуглил, нарыл 2 параметра:
    net.link.gif.max_nesting = 20
    net.link.gif.parallel_tunnels = 1

    sysctl -a говорит что параметры применились, но после перезагрузки вижу те же ошибки и ни чего не работает.

    Подскажите пожалуйста как можно полечить проблему, и можно ли вообще ...


  • Добрый
    @kharkov_max

    net.link.gif.max_nesting = 20
    net.link.gif.parallel_tunnels = 1

    Для постоянного хранения это прописывается в /boot/loader.conf.local по аналогии с https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#intel-ix-4-cards
    Или в вебке есть раздел по добавлению переменных (лучше).

    Возникла необходимость создать вложенный GRE тунель.

    Если не секрет, то зачем?


    1. Переменные сохраняются через web, в штатных "System Tunables" их нет, но добавить позволяет.

    2. Зачем ...
      Нужно соеденить mikrotik (2 wan) и Pfsense 1 wan. через ipsec
      В виду того что mikrotik не может создать 2 ipsec туннеля на один peer, приходится городить огород.
      GRE1-IPSEC-GRE2
      На GRE2 ospf ...
      Между mikrotik такая схема работает, а с pfsense, возник вопрос, туннель в туннеле...


  • @kharkov_max
    openvpn?


  • Хочется IPSEC ....
    Т.к. Openvpn на mikrotik работает только на одном ядре и только по TCP.
    С OpenVPN знаком, пользователи конектятся удаленно по нему, а вот офис хочу через IPSEC завязать...


  • @kharkov_max
    В 7-й же бэте добавили и udp и wireguard https://habr.com/ru/news/t/516108/
    Или костылить с ipsec как вы и пытаетесь.


  • @kharkov_max Используйте обычный Site-to-Site Tunneling IPsec, зачем городить GRE


  • @viktor_g

    @kharkov_max said in Вложенные GRE тунели:

    В виду того что mikrotik не может создать 2 ipsec туннеля на один peer


  • День добрый.

    Не хочу плодить темы, спрошу помощи тут.
    Mikrotik может строить 2 тунеля на один peer, с чего я думал до этого что не может это 3й вопрос, был такой опыт в более старых прошивках, возможно эту возможность реализовали, попробовал - получилось создать 2 пира на один IP.

    В связи с этим вложенные тунели не нужны.
    Решил поднять IPSEC site-to-site + GRE + OSPF, стандартная схема примеров в инете куча.
    Как шаблон использовал этот пример

    Ради простоты 2й тунель не поднимаю, хоть бы один заработал ...
    В итоге, IPSEC поднимается, GRE нет.
    При этом иногда, при каких то обстоятельствах все же поднимается и работает.
    Стоит перегрузить PFSENSE - опять не поднимается ...
    Мучаюсь уже несколько дней, весь инет перерыл - не могу понять в чем дело.
    Собственно настройки как по статье.

    Может есть какие то особенности ? Что то нужно глобально подкрутить?
    Еще обратил внимание, если peer mikrotik перевести в пассивный режим, то pfsense к mikrotik не подключается...

    Заранее спасибо за помощь.


  • Методом тыка, обнаружил что все нормализуется и начинает работать как нужно, после сброса состояний "Reset state". Работает до первой перезагрузки и потом опять необходимо сбрасывать стояние фаервола и нат....


  • @kharkov_max
    Здр
    Еще раз повторюсь , писал уже несколько раз
    Логика инициализации PF такова - сначала поднимается GRE , а потом уже IPSEC ( должно быть все наоборот ) . Из-за этой последовательности GRE сразу после перезагрузки не работает . Увы .
    Я думал поменять эту последовательность , изменив скрипты , но побоялся все поломать. Решение такое - перед тем как перегрузить PF, отключаете GRE интерфейс
    4c1c4db3-83c1-49ca-b28e-440cc565fa58-image.png
    сохраняетесь и перезагружаетесь
    после перезагрузки и убедившись , что ipsec поднялся , запускаете GRE интерфейс.
    Где-то читал , что срабатывает такой скрипт
    ifconfig gre0 down
    ipsec restart
    ifconfig gre0 up


  • Добрый день.

    Проверил Вашу последовательность действий.
    Т.е. отключил GRE интерфейсы, перезагрузил PF, убедился что IPSEC работает с обоих сторон, включил GRE интерфейсы.
    После данных манипуляций GRE не поднялся, только после reset state.

    Так же по рекомендации переключил шифрование с обеих сторон только на 47й протокол.
    Последствия костыля понимаю, делал осознанно.

    В процессе тестирования попал на еще один момент, после выключения GRE и перезагрузки, PF перестал быть доступен из интернет, при этом PF инет видит.
    Похоже что виной были правила прописанные для GRE интерфейса во "Floating".
    Если остается активным хоть одни GRE, то шлюз грузится и доступен из интернет после перезагрузки, если выключаешь все GRE интерфейсы, то видимо правила Floatin не верно отрабатывают, при этом pfctl -d не решает проблему ...
    Приходилось через консоль откатывать конфигурацию.
    После того как правила перенес непосредственно в каждый интерфейс GRE и почистил Floating, проблема с недоступностью после перезагрузки прекратилась...

    Может я что то упускаю из глобальных настроек или настроек NAT или Advanced Settings ipsec?
    В принципе NAT в туннеле мне не нужен, но в PF включен NAT на WAN any to any tcp/udp.


  • @kharkov_max
    Сложно о чем-то судить удаленно
    Но , вот , к примеру , мои настройки для GRE ( правила Floating )
    все чудесно работает ( но активация интерфейса идет по моему алгоритму )

    859600bb-d4e7-4040-bcb6-afde4c7e6d90-image.png

    3d110afa-f227-40d5-9b75-4d851f9f64a5-image.png
    71195d3b-33cc-4ef8-9775-2a822431bbfb-image.png

    ifconfig | grep gre
    gre0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400 inet6 fe80::208:a2ff:fe0a:ff72%gre0 prefixlen 64 scopeid 0x9 groups: gre 
    gre1: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1400 inet6 fe80::208:a2ff:fe0a:ff72%gre1 prefixlen 64 scopeid 0xa groups: gre 
    
    

  • Может я уже что то наковырял в глобальных настройках ...
    Если не тяжело можете показать настройки Advanced "Firewall & NAT", "Networking", "Miscellaneous" и "System Tunables"?


  • @kharkov_max
    Напишите мне в личку , если не сложно


  • @kharkov_max
    Покажите , пож , правила на интерфейсах Lan, Wan и GRE
    вывод команд из консоли
    ipsec statusall
    и ifconfig -m


  • @Konstanti said in Вложенные GRE тунели:

    ifconfig -m

    > ipsec statusall
    Status of IKE charon daemon (strongSwan 5.8.4, FreeBSD 11.3-STABLE, amd64):
      uptime: 21 minutes, since Nov 25 13:12:14 2020
      worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
      loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac drbg curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam whitelist addrblock counters
    Listening IP addresses:
      1.1.1.1
      172.16.5.14
      10.0.8.1
      10.10.30.1
      10.10.30.5
    Connections:
       bypasslan:  %any...%any  IKEv1/2
       bypasslan:   local:  uses public key authentication
       bypasslan:   remote: uses public key authentication
       bypasslan:   child:  172.16.5.14/32|/0 === 172.16.5.14/32|/0 PASS
         con2000:  1.1.1.1...2.2.2.2  IKEv2, dpddelay=10s
         con2000:   local:  [1.1.1.1] uses pre-shared key authentication
         con2000:   remote: [2.2.2.2] uses pre-shared key authentication
         con2000:   child:  1.1.1.1/32|/0[gre] === 2.2.2.2/32|/0[gre] TRANSPORT, dpdaction=restart
         con4000:  1.1.1.1...3.3.3.3  IKEv2, dpddelay=10s
         con4000:   local:  [1.1.1.1] uses pre-shared key authentication
         con4000:   remote: [3.3.3.3] uses pre-shared key authentication
         con4000:   child:  1.1.1.1/32|/0[gre] === 3.3.3.3/32|/0[gre] TRANSPORT, dpdaction=restart
    Shunted Connections:
       bypasslan:  172.16.5.14/32|/0 === 172.16.5.14/32|/0 PASS
    Routed Connections:
         con4000{8}:  ROUTED, TRANSPORT, reqid 2
         con4000{8}:   1.1.1.1/32|/0[gre] === 3.3.3.3/32|/0[gre]
         con2000{7}:  ROUTED, TRANSPORT, reqid 1
         con2000{7}:   1.1.1.1/32|/0[gre] === 2.2.2.2/32|/0[gre]
    Security Associations (2 up, 0 connecting):
         con4000[4]: ESTABLISHED 21 minutes ago, 1.1.1.1[1.1.1.1]...3.3.3.3[3.3.3.3]
         con4000[4]: IKEv2 SPIs: d16ce785cc16854f_i bcb9e71bae5403c8_r*, rekeying disabled
         con4000[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
         con4000{6}:  INSTALLED, TRANSPORT, reqid 2, ESP SPIs: c6b68f56_i 07541b66_o
         con4000{6}:  AES_CBC_256/HMAC_SHA2_256_128, 131197 bytes_i (2343 pkts, 0s ago), 258080 bytes_o (2332 pkts, 0s ago), rekeying disabled
         con4000{6}:   1.1.1.1/32|/0[gre] === 3.3.3.3/32|/0[gre]
         con2000[3]: ESTABLISHED 21 minutes ago, 1.1.1.1[1.1.1.1]...2.2.2.2[2.2.2.2]
         con2000[3]: IKEv2 SPIs: a2d5dd7f9bf001ec_i 56f27de4f84f1e08_r*, pre-shared key reauthentication in 7 hours
         con2000[3]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
         con2000{9}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c09bd08c_i 02845107_o
         con2000{9}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_1024, 151005 bytes_i (2162 pkts, 0s ago), 270616 bytes_o (2162 pkts, 0s ago), rekeying in 5 minutes
         con2000{9}:   1.1.1.1/32|/0[gre] === 2.2.2.2/32|/0[gre]
    
    ifconfig -m
    vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
            capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>
            ether 00:00:00:7b:11:2e
            hwaddr 00:00:00:7b:11:2e
            inet6 fe80::8400:ff:fe7b:142e%vtnet0 prefixlen 64 scopeid 0x1
            inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            media: Ethernet 10Gbase-T <full-duplex>
            status: active
            supported media:
                    media 10Gbase-T mediaopt full-duplex
    vtnet1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
            capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>
            ether 00:00:00:6b:58:ee
            hwaddr 00:00:00:6b:58:ee
            inet6 fe80::7400:ff:fc7b:48ee%vtnet1 prefixlen 64 scopeid 0x2
            inet 172.16.5.14 netmask 0xffffffff broadcast 172.16.5.14
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            media: Ethernet 10Gbase-T <full-duplex>
            status: active
            supported media:
                    media 10Gbase-T mediaopt full-duplex
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
            options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
            capabilities=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
            inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
            inet 127.0.0.1 netmask 0xff000000
            inet 10.255.255.1 netmask 0xffffffff
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            groups: lo
    enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            groups: enc
    pfsync0: flags=0<> metric 0 mtu 1500
            groups: pfsync
    pflog0: flags=100<PROMISC> metric 0 mtu 33160
            groups: pflog
    ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
            options=80000<LINKSTATE>
            capabilities=80000<LINKSTATE>
            inet6 fe80::9489:34ad:4a91:941e%ovpns1 prefixlen 64 scopeid 0x9
            inet 10.0.8.1 --> 10.0.8.2 netmask 0xffffffff
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            groups: tun openvpn
            Opened by PID 36265
    gre0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1422
            options=80000<LINKSTATE>
            capabilities=80000<LINKSTATE>
            tunnel inet 1.1.1.1 --> 3.3.3.3
            inet 10.10.30.1 --> 10.10.30.2 netmask 0xfffffffc
            inet6 fe80::9489:34ad:4a91:941e%gre0 prefixlen 64 scopeid 0x7
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            groups: gre
    gre1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1422
            options=80000<LINKSTATE>
            capabilities=80000<LINKSTATE>
            tunnel inet 1.1.1.1 --> 2.2.2.2
            inet 10.10.30.5 --> 10.10.30.6 netmask 0xfffffffc
            inet6 fe80::9489:34ad:4a91:941e%gre1 prefixlen 64 scopeid 0x8
            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
            groups: gre
    

    WAN
    WAN-PFSense.jpg

    LAN
    Lan-PFSense.jpg

    GRE

    Any to ANY, protocol Any, TCP Flags - Any flags (check), State type - None


  • @kharkov_max
    Так я криминала не вижу
    Попробуйте маску поменять у GRE туннеля на /24


  • @Konstanti
    Я думаю не обязательно 24, может любую другую отличную от 30 ?


  • @kharkov_max
    Можно и так ( но попробуйте /24 )
    и сделайте так , чтобы туннели были в разных сетях , а не подсетях одной сети
    это же не принципиально для вас ?


  • По маске они и так в разных сетях )))
    Ок, сделаю 30ю и 31ю /24


  • @kharkov_max
    Я вижу это , но при маске /24 они в одной сети будут )
    Поэтому и предлагаю их разнести в разные сети даже при маске / 30


  • Сделал - результат такой же.
    После ребута PF GRE не восстановился, после reset state - все заработало.


  • @kharkov_max
    а в журналах есть какие-нибудь ошибки , касающиеся GRE ?


  • Есть вот такое

    /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use GRE_NAME_TUN
    

  • В момент загрузки до reset state, но оно и логично ...

    GRE_Name1_TUNNELV4 10.10.30.2: sendto error: 13
    GRE_Name2_TUNNELV4 10.10.31.6: sendto error: 13 
    

  • @kharkov_max
    Отключите мониторинг доступности GRE канала
    4f4fe316-247a-4c8a-996f-d6473894b62e-image.png
    и еще вопрос - я верно понимаю , что при перезагрузке Вы отключаете GRE интерфейс


  • На данный момент при перезагрузке я не отключал GRE


  • @kharkov_max
    Повторюсь

    Цитата из интернета
    Во время загрузки системы конфигурирование интерфейсов GRE происходит раньше, чем IPSec VPN. Что приводит к сбою в работе GRE.
    Попробуйте автоматизировать этот процесс таким скриптом после загрузки ( не факт , что сработает )

    #!/bin/sh
    
    IFCONFIG=`ifconfig`
    AWK=`awk`
    INTERFACES=`${IFCONFIG} | ${AWK} '{ gsub(/\t/, " "); print }' | cut -c1-8 | sort | uniq -u | ${AWK} -F: '{print $1;}' | grep gre`
    
    for if in ${INTERFACES};
    do
    
    ${IFCONFIG} ${if} down
    ${IFCONFIG} ${if} up
    
    done
    
    exit 0
    

  • Сделал еще один тест, выключил GRE, перезагрузился, убедился что IPSEC поднялся, включил GRE - GRE не поднимается.
    Тут момент, PF говорит что GRE UP, а на стороне mikrotik GRE DOWN.
    Делаю reset state - со стороны mikrotik GRE мгновенно UP и все начинает работать.

    Скрипт этот видел и пробовал - не работает, по сути он выключает и включает все GRE интерфейсы ... Это то что можно через Web интерфейс сделать руками.

    Какие еще могут быть варианты?
    По сути что делает reset state, перезагружает pf ?


  • Решил проблему с перезагрузкой и поднятием GRE следующим костылем.
    Поставил утилиту Cron и добавил в нее:

    @reboot root /usr/bin/nice -n20 /sbin/pfctl -F state
    

    Пусть при загрузке PF всегда сбрасывает состояния, проверил - работает.
    Можно сбрасывать только с определенными ИП...
    И не нужно интерфейсы выключать и т.д....

    Хотя я не понимаю почему у других отключение интерфейсов работает, а у меня нет ...


  • Доработал дергалку до вида

    /usr/bin/nice -n20 /bin/sleep 60 && /usr/bin/nice -n20 /sbin/pfctl -F state