@Redbob

172.24.38.1 doesnt have a route to 10.254.124.0/24.
Your options are either to

create static routes on each hop. use dynamic routing protocols such as OSPF or BGP.

Phase1
35d54499-95cc-4bc7-a19f-ee36e9d26922-image.png
0853b47a-24d0-4420-8a19-dc9ec1f62e37-image.png
502b6db4-5a9d-4491-a3dd-84362f44c8b1-image.png
Phase2
edf50591-7508-479b-8fb7-ba94baef191b-image.png
b8a82af2-cf39-4d62-9ac4-2164ef4eab88-image.png
Mobile Client section
186d59c4-d427-48e6-a5b6-23d069f88e59-image.png cc306b4c-5e64-49d5-8ee0-4f60bb14ee65-image.png
3068fe04-9607-470e-a8c9-d7324e97b0e9-image.png

You might be able to make it work using Routed VTI interfaces. So you would need 3 distinct IPSec connection, one for each gateway. Each connection would be in Routed VTI mode under Phase2. You then define a /30 address space for each tunnel pair. You can then run OSPF on these "VTI" and assign different priorities. So when all is said and done, from your side, you would have 3 next hops to the remote network. If the IPSec tunnel is down to a gateway, obviously it won't show up in your routing table since the routing protocol would detect that. The routing protocol priority would determine which gateway you would use first if all 3 tunnels are up at the same time.

@jba
Glade that you got it working.
You're right, all subnets you want to connect across the IPSec need to be stated in a phase 2 as well.

Hi,
I'm facing exactly the same issue. I presume that after 2 years, you found the root cause.
Could it be possible to let us know the solution ?
Thanks for your feedback.
Cheers.

@luckman212 In the sense that I found that it couldn't be done like this with the results that I wanted, yes. In effect, this seems to be how HA is intended to work.

We changed our approach and avoid using the CARP interface for any IPSEC traffic. We have a separate VTI tunnel connecting from both the primary and secondary router to each of the routers at the remote location. This requires a separate public IP for each router on each WAN, of course, and if both locations have dual routers then it requires a second virtual IP (not CARP) for each router as well. For example, routers A & B are at one location, and routers C & D are at a second location. A1.1 is the primary WAN1 interface on router A, A1.2 is the secondary IP address for WAN1 on router A. A1.1 connects to C1.1, B1.1 connects to D1.1, A1.2 connects to D1.2, B1.2 connects to C1.2. Repeat for WAN2 connections. Then do it all again to cross them (A1.1 to C2.1, B1.1 to D2.1, etc.). All VTI tunnels are up all the time. Then use your routing settings to weight the routes as needed. Remember to exclude your VTI addresses from being published by your routing protocol, or you may get some weird things like routing traffic over an existing VTI tunnel to get to a second VTI endpoint address in an attempt to establish one of the other tunnels, which of course fails.

The routing protocol then becomes the primary determining factor in failover time. For each situation where both locations have 2 WANS and 2 routers, I have 16 VTI tunnels connecting the 4 routers so that I have full redundancy between routers and WANs. If you have only 1 router or only 1 WAN, or if you can't get enough public IP addresses from your ISP, it gets simpler very quickly.

I solved the problem.
The problem was the duplicate session.
I solved it with the help of: https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec-duplicate-sa.html

Are both devices here pfSense?

I've had a similar issue before where I was using the peer identifier as it's IP address on an IPSec VPN and for some reason it would just not authenticate, manually specifying the same IP that was being used automatically ended up fixing the issue, it was a very odd bug (I would assume, I'm quite experienced with IPSec) from a while back, ended up rebuilding the VPN recently but went back to using the peer IP and it authed totally fine.

Are you on the latest pfSense?

Here is my original post about this from a while ago, it may not be the exact thing you are facing but sounded similar, never did get any replies from it (though I haven't encountered it again yet so I'm not to worried about it unless yours ends up being the same issue).

https://forum.netgate.com/topic/176502/had-to-manually-specify-identifier-ip-address-no-nat-involved-bug

This is super odd, we are connect back and passing traffic out of the blue - could this be some really crazy ISP thing?

Re: Netgate 6100 PfSense to Edgerouter Lite - IPSEC site-to-site - works with PSK but NOT with PKI / X509

If anyone comes across this, I was able to resolve it. The Edgerouter/EdgeOS software is picky about the names.

On the PfSense side, the "My Identifier" field needs to be set as "FQDN", and must contain the SAN in the certificate. If no SAN, most likely the CN (common name) will work, as it did in another test.

f9deede4-a2ad-4ef2-8af1-b4026980411c-image.png

Note that in my attached picture, the SAN (subject alternative name) LOOKS like a FQDN, but it is actually just a name.

I hope this saves someone else 4 days of troubleshooting : )

@viragomann
https://drive.google.com/file/d/1U4xVpBn2VD4lW1foMkEwjUCVFd-gpfTd/view?usp=drivesdk

Firewall has started negotiating with router which is next to it, instead of actual another pfsense firewall. In the red box there should be ip address of another firewall... please help

@will2liv said in IPsec VPN between version 2.7.0-RELEASE and 2.4.0-RELEASE:

Router 1 which is remote and I don't have physical access to is running pfSense Version 2.4.0-RELEASE. The system says "The system is on the latest version."

Did you try to select a newer branch in System > Update?