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

viktor_g

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

werter

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

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

kharkov_max

День добрый.

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

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

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

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

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

kharkov_max

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

Konstanti

@kharkov_max
Здр
Еще раз повторюсь , писал уже несколько раз
Логика инициализации PF такова - сначала поднимается GRE , а потом уже IPSEC ( должно быть все наоборот ) . Из-за этой последовательности GRE сразу после перезагрузки не работает . Увы .
Я думал поменять эту последовательность , изменив скрипты , но побоялся все поломать. Решение такое - перед тем как перегрузить PF, отключаете GRE интерфейс

сохраняетесь и перезагружаетесь
после перезагрузки и убедившись , что ipsec поднялся , запускаете GRE интерфейс.
Где-то читал , что срабатывает такой скрипт
ifconfig gre0 down
ipsec restart
ifconfig gre0 up

kharkov_max

Добрый день.

Проверил Вашу последовательность действий.
Т.е. отключил 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.

Konstanti

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

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

kharkov_max

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

Konstanti

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

Konstanti

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

kharkov_max

@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

LAN

GRE

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

Konstanti

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

kharkov_max

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

Konstanti

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

kharkov_max

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

Konstanti

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

kharkov_max

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

Konstanti

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

kharkov_max

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

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

kharkov_max

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

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