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?

@michmoor Thanks so much for the response. After further digging, it turns out that I was just being dumb and not paying attention to what I was doing. I was jumping from adapter to adapter, connection to connection running around the building with my laptop. I didn't realize that the dock I had plugged into left me wireless.

Once I figured out I was chasing my tail and wired myself, I was able to all but max out the connection at 35MB/s. I also looked and one site is 500/500 and the other is 300/300., so the 35MB/s makes complete sense.

With that said, I'm going to bump up the second site to 500/500 on Monday. Any suggestions on how to pair the IPsec settings with the settings for the cryptographic hardware?

@aryanrai
Did you add firewall rules to the IPSec interfaces to allow access from the other site?

Or do you try to ping the LAN device in the other network? In this case you have to ensure that the device also allows access from a remote network. For testing disable its firewall.

Thanks @jimp - I found that out with additional reading, so changed tack and now am using OpenVPN with ESET Secure Authentication, which works well and provides convenient push authentication.

Just want to reply here my discoveries, to save people the hassle of attempting this to find out it does not work, there are two types of GRE tunnels, GRETAP and GRETUN, one supports layer 2 features such as broadcast/multicast and one does not, the PFSense implementation appears to use the later which does not support this feature, please see the following article to show the difference

https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels#:~:text=While%20GRE%20tunnels%20operate%20at,header%20in%20the%20inner%20header.

You would need a local UDP relay instead (on the client side) to instead allow the client to relay these broadcast message as unicast to a specific host, I struggled with this for Windows File Sharing (WS-Discovery) broadcast packets and ended up resorting to a script that auto maps all network drives on successful client connection, perhaps someone could get this working with a L2TP on top of Wireguard?

https://github.com/sparky3387/automapwireguard - Shameless plug of the automap script if someone else also needs this.........