UPDATE:

I've been doing some tests trying to know where the problem is and it seems that finally it comes from WAN interface. I configured first WAN but until I configured the IPSEC tunnels the problem didnt appear.

Today I reinstall a fresh pfsense and first of all I configured the tunnels with no problems and when I configured the WAN the problem start. If I enable WAN with DHCP or Static IP without a gateway it works everything fine, when I choose a IPv4 Upstream gatewy then return the problem.

At this point this topic can be closed.

@sdedurana a error in config. Solved. Please close.

@keyser Oof. Sounds like I'm in unsupported configuration territory here.

I'll see how it performs in a lab.

@joshopkins
Seems all the settings you did are correct, apart from the push-route commands in the default options. These do the same as the "local networks" setting does, which is the preferred way. You shouldn't have both settings.

Ensure that the access is allowed by rules on all incoming interfaces. Means on the OpenVPN interface at B and on the IPSec of A and C.

To see what's going on, sniff the traffic on the involved interfaces, while you try to access a remote IP from an OpenVPN client.

Wanted to add a bit more info here as this issue remains even after upgrading to 2.6.0 today.

My tunnels are IKEv2 in VTI mode.

Under Phase 1 Advanced Options, I set "Child SA Start Action" to "Initiate at start (VTI or Tunnel Mode)"
and
"Child SA Close Action" to "Restart/Reconnect"

Under Phase 2 > Keep Alive, I use a host on the other side of the tunnel with Keep Alive "Enable periodic keep alive check".

The tunnels do not establish if I shut down the MASTER CARP node or "Enter Persistent CARP Maintenance Mode" on the MASTER CARP node. I have to click Connect to manually establish the tunnels.

Seeing these messages in the IPsec System Log
charon[43289]: 04[CFG] trap not found, unable to acquire reqid 5002

Have anyone else seen this issue?

@shahidge4
The tcpdump from WAN is pretty useless, since the connection is established already.

Your P2 has a single remote IP. So the VPN will only allow access to this one.
Do a packet capture on the IPSec interface.

Ensure that the remote host does not block access from the remote network.

So the P2 will effectively end up being (in my example) 10.200.10.0/24 to 10.100.10.0/24.
Each side 'hides' it;s local 10.10.10.0/24 subnet behind another, same sized, subnet. You could use any unused subnet for that I just chose 10.100.10.0 and 10.200.10.0.

So on each side that would be the Binat address.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

However if you do not need access between the two subnets dircetly but only from the pfSense_1 OpenVPN subnet this becomes easier. You only need to BiNAT on the pfSense_2 side like:

Screenshot from 2022-05-12 14-02-05.png

On the pfSense_1 side the P2 would be just be 172.10.10.0/24 to 10.100.10.0/24

To access the remote side VPN clients would need to use the equivalent NAT address.

Steve

Merci @nicolas-R je vais tester t'as solution.

Well according to this documentation NHRP via FRR is not available for FreeBSD. 😞

http://docs.frrouting.org/en/latest/overview.html#feature-matrix