[solved] IPSec concentrator behind a Netgate box

Frankye

We have an IPSec concentrator (a random box with pfsense on, nothing fancy) behind our main firewall (a netgate box). Said IPsec concentrator is supposed to connect to other people's and bring up lan to lan tunnels.

other people's LAN
    |
remote concentrator
   |||
   www
   |||
MultiWAN HA Netgate firewall 
(tunnel should pass through)
   |||
 Our LAN
   |||
Pfsense box
(does the IPsec)
    |
DMZ for other people's stuff

I did have multiple tunnels up at once. But that was with the old non-HA netgate box. It has been just one tunnel for a year or so.

Until last week when I tried to configure another tunnel and failed miserably.

It seems that ISAKMP traffic from the remote Fortigate unit is correctly translated and forwarded to the internal box.
However the responses are not translated back. Or at least that's what I seem to get from packet captures on the firewall.

I am translating ESP, AH, ISAKMP and NAT-T...

inbound:

outbound:

The aliases point to the internal box (ipsecgw) and the external concentrators' public IPs.
The IP address the whole thing is natted on is a CARP VIP (not sure if useful, but before it was a normal IP alias)

I have firewall rules on both interfaces allowing the traffic and redirecting it to the right gateway. No NAT reflection.

A dump on both interfaces does not show much I'm afraid:
(external above, LAN below)

The most maddening thing is: the other IPSec tunnel on the concnetrator works like a charm.

Only differences that I can see are:

working one is aggressive mode to a cisco unit
not working one is main mode to a fortigate unit

.
Could anyone give me an idea on where to check? So far I read all the documentation I could find but did not find anything to help.

Frankye

I managed to ... sort of solve it.

Netgate support told me to try and put each tunnel on a different internal IP alias.
After doing that (and creating the relative NAT and firewall rules on the border box) the second tunnel got up.

I still have no idea why this is the case exactly, but I'll take the working tunnel over understanding pfsense's IPSec and/or NAT mechanics for now.