IKEv2 multiple phase 2 - negotiations for one network only

Peter2121 0

Hello,

I'm trying to establish a tunnel between pfSense 2.5.0 and a FreeBSD 13.0 host with Strongswan 5.9.5 installed. I need to connect one remote network (jails VNET) and two local networks, directly connected to pfSense. I want to use IKEv2 with NAT-T (as the host is situated behind NAT device). The two networks at pfSense side are not overlapped.
If I configure one phase 2 at both sides - everything works correctly, the tunnel works for any local network. So I don't have problems with IKE negotiations.
If I configure 2 tunnels - only one network (the first one configured at pfSense side) can be used.
Analysing the logs at Strongswan side, I see the interesting events sequence.

Starting (or restarting) Strongswan, it connects to pfSense (already configured), negotiates phase 1 and two phase 2. All SAs are correct, both tunnels are up and running. The traffic pass by the two tunnels.
In some seconds pfSense comes to negotiate phase 1
The phase 1 is negotiated, then pfSense negotiates ONE phase 2 (and ONLY ONE)
The negotiations are successful, the server now have new SA for phase 1 and for one phase 2
The server deletes old SA for the phase 1 and tries to delete SAs for two old phase 2. The first (renegotiated) SA for the phase 1 remains, the second (not proposed by pfSense for negotiations) is deleted
Only one tunnel remains up, the second goes down.

A workaround for me is to disable the uniqueness of SA at server side, so initially negotiated tunnels remain active - the traffic passes.

So, my questions are

Why does pfSense come to renegotiate phase 1 and phase 2 when the both are already negotiated, the both tunnels are up and the traffic passe?
Why does pfSense propose only one phase 2 for negotiations, having two tunnels configured?

I know, the pfSense version is a little bit old, but the upgrade is difficult as there is a traffic 24/7. I would like to be sure that the upgrade fixes my problem, before trying to initiate the upgrade.

Peter

mamawe

@peter2121-0 We can't answer your questions without knowing the configuration and logs (at least I can't).

Kind regards,
Mathias

Peter2121 0

Hello,
I did not suppose to ask for a complete analysis of the problem as the configuration is complex, so it will certainly take much time.
I just ask what could be a reason of such strange behavior, and how can I debug the problem myself at pfSense side. As the configuration of Strongswan is managed by pfSense scripts, I cannot understand even how can I find the real configuration files used by Strongswan. So, I would like to get help in debugging the problem myself.
Peter

mamawe

@peter2121-0 Speculating what could be the reason is best done having a beer in one hand and the logs in the other. ;-)

Seriously:
If you want to debug the problem yourself, there are a few things

You can find the Strongswan configuration generated by the web interface below /var/etc/ipsec.
To filter the logs, go to Status / System Logs / IPsec and then filter first for the peer address and afterwards for the connection id (something like <con2000|1>), that you get from a log line containing the peer address.
The connection ID is also available at the CLI using ipsec statusall if there are not that many VPNs configured.
At VPN / IPsec / Advanced Settings you can fine tune the logging.

I hope that helps to get you started with debugging your VPN.

Peter2121 0

It was a problem of sharing multiple destination networks in one child configuration (at pfSense side). Activation of 'Split connections' option seems to solve my problem.
As I manage manually the configuration files at server side, it is more simple for me to have separate children (one child per network).
Thanks for the assistance!