FRR nhrpd not able to communicate with strongswan vici

[fl0schi]

---

Describe the bug

After a fresh installation FRR is not able to communicate with strongswan vici.
I installed FRR via official repository (see version below). Strongswan was installed in version 5.9.5 and patched successfully with patches from the mentioned maintained repo in FRR docs.
Please find the config of strongswan and FRR below in the screenshot section.
If no 'tunnel protection' is used within the gre1 interface everything works fine - I see nhrp neighbors, as well as my routing information via BGP. If I enable the 'tunnel protection' (and ofc I want and need that..), FRR shows the following error:
Sep 19 17:23:25 spoke.domain.tld nhrpd[4295]: [YJY20-VM0HB][EC 117440513] VICI: strongSwan: CHILD_SA config 'dmvpn' not found
In strongswan I see:
Sep 19 17:23:25 spoke.domain.tld charon-systemd[4177]: vici initiate CHILD_SA 'dmvpn'
at the same time, so it looks like it's trying to initiate the session correctly?
On the HUB I don't see any errors, but also no attempts.
I'm a little bit confused why FRR is saying it doesn't find the config for my "dmvpn" profile.
Hopefully someone can help me out, and if I can provide further info - please let me know.
Thanks in advance! :-)

• Did you check if this is a duplicate issue?
• Did you test it on the latest FRRouting/frr master branch?

To Reproduce

1. Fresh installed Debian 11 server
2. Install FRR from repo
3. Build, patch and install strongswan 5.9.5
4. Config like in the docs
5. Try to initiate the tunnel(s)
6. See error

Expected behavior

Tunnel(s) in FRR up and running.
Routing information exchanged like they're without tunnel protection.
Working setup with encryption.

Screenshots

FRR configuration of HUB:

frr version 8.3.1
frr defaults traditional
hostname hub.domain.tld
log syslog informational
nhrp nflog-group 1
nhrp multicast-nflog-group 2
service integrated-vtysh-config
!
ip router-id 172.20.0.20
!
interface gre1
 description DMVPN HUB - BRAVO
 ip address 10.0.0.20/32
 ip nhrp holdtime 3600
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 ip nhrp registration no-unique
 ip nhrp shortcut
 no link-detect
 tunnel protection vici profile dmvpn
 tunnel source eth0
exit
!
router bgp 65000
 bgp router-id 172.20.0.20
 no bgp ebgp-requires-policy
 neighbor SPOKES peer-group
 neighbor SPOKES disable-connected-check
 neighbor 10.0.0.30 remote-as 65003
 neighbor 10.0.0.30 peer-group SPOKES
 !
 address-family ipv4 unicast
  network 172.20.0.20/32
 exit-address-family
exit
!

FRR configuration of SPOKE:

frr version 8.3.1
frr defaults traditional
hostname spoke.domain.tld
log syslog informational
nhrp nflog-group 1
nhrp multicast-nflog-group 2
service integrated-vtysh-config
!
ip router-id 172.20.0.30
!
interface gre1
 description DMVPN SPOKE
 ip address 10.0.0.30/32
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp nhs dynamic nbma <ext-ip-of-hub>
 ip nhrp redirect
 ip nhrp registration no-unique
 ip nhrp shortcut
 no link-detect
 tunnel protection vici profile dmvpn
 tunnel source eth0
exit
!
router bgp 65003
 no bgp ebgp-requires-policy
 neighbor 10.0.0.20 remote-as 65000
 neighbor 10.0.0.20 disable-connected-check
 !
 address-family ipv4 unicast
  network 172.20.0.30/32
 exit-address-family
exit
!

strongswan config on both:

config setup

conn dmvpn
    authby=secret
    auto=add
    keyexchange=ikev2
    ike=aes256-aes256-sha256-modp2048
    esp=aes256-aes256-sha256-modp2048
    dpdaction=clear
    dpddelay=300s
#    left=%any
#    leftid=%any
#    right=%any
#    rightid=%any
    leftprotoport=gre
    rightprotoport=gre
    type=transport
    keyingtries=%forever

# ipsec.secrets - strongSwan IPsec secrets file
%any : PSK "super-secret-ofc"

Versions

• OS Version:
  Debian GNU/Linux 11 (bullseye)

• Kernel:
  Linux 5.10.0-18-amd64 1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux

• FRR Version:
  frr/stable,now 8.3.1-0~deb11u1 amd64

Additional context

Unfortunately, I tried it months ago with the same result and stopped working on it due to that issue.
Now I want to fix it, but it looks like I definitely need help - I hope someone out there knows what's going on here and can tell me what I'm doing wrong.
I am talking about two VPS, different providers and I want to create a full-meshed "dmvpn" setup with all my other locations (VPS, road-warrior, homes, etc.). The two test VPS have a dedicated internet access, a loopback which is announced via BGP and ofc a GRE interface for the tunneling.
Thanks in advance for your assistance. 👍

[gh0813]

Hello, I encountered a problem similar to yours. My environment is NHRP cooperating with bgp, but I found the possible cause of the problem. You can check the link I sent. This is the problem I released to see if it can help you

#11975

[fl0schi]

Hello, I encountered a problem similar to yours. My environment is NHRP cooperating with bgp, but I found the possible cause of the problem. You can check the link I sent. This is the problem I released to see if it can help you

#11975

Unfortunately, I don't think it's similiar - I'm not having any trouble with the routing, that works fine. The routes are also in the routing table of the local system.
My issue is related to the communication with strongswan, which is still not working. :-(
Do you use strongswan for IPSEC encryption?

[gh0813]

Hello, I encountered a problem similar to yours. My environment is NHRP cooperating with bgp, but I found the possible cause of the problem. You can check the link I sent. This is the problem I released to see if it can help you
#11975

Unfortunately, I don't think it's similiar - I'm not having any trouble with the routing, that works fine. The routes are also in the routing table of the local system. My issue is related to the communication with strongswan, which is still not working. :-( Do you use strongswan for IPSEC encryption?

Unfortunately, my environment does not work with ipsec...

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.