I'll reply to my own question, as I kind of fixed it.
After inspecting the traffic via tcpdump, I saw that packets with a length of 1448 and over were not being passed through the tunnel. Went on both PFSenses, System -> Advanced -> Firewall & NAT and check Enable Maximum MSS, setting it to 1400 - even though the default is 1400.

After doing this on both sides (later tests revealed that it's enough to do it on one side), HTTPS connections started to work properly.

Anyone got any clue what might have happened though?!

Some update on this: on the A side there are attached other networks over OVPN still in shared key mode... So from site B i can reach ALL(!) other networks fine independed of the gateway i use... Only the local attached networks of site A have problem from side B if i go through the second wan line.. Does anyone has any idea on how to trace the problem?

@teverett Don't know...have you tried searching your error/issue in the redmine site? That's where bugs/fixes live. I just searched for that one filename above. I see your post linked above. If the issue is reproducible and there's no redmine open I'd open one.

My android will not even connect to even external AP WiFi in 23.09. Other devices connect just fine.

@anthony-breen If are trying to work with other brand, add more algo in phase 1 and phase 2, if u don't have the doc where u can see what algo he need u need to do reverse eng. Add more, maybe he is searching for less secure algorithms.

The only issue is that if u are in pfsense 2.7.x and they request less secure algorithms, U will be not be able to make work.

phase.png

@dsmoljan not possible, I ask the same!!!

@keyser is a shame, but well is a feature that will be great to have.
Any way thanks for your info!!!

@periko hi thanks for the reply, i ended up just putting the IP of the fortigate WAN ip and NAT

Got it, so is not a must to have this for reaching other side's computers :)

@HKFEVER

Confused.

Remote client's subnet is 192.168.5.0/24

Site B IP is 28.37.35.162, subnet is 192.168.2.0/24:
Tunnel B <-> C:
P1 is connect to Remote Gateway 38.37.35.162
P2 is connect to Remote Gateway's network 192.168.3.0/24 (this is Site A's subnet)
For additional 2nd P2, what network should I put in?

Tunnel B <-> A:
P1 is connect to Remote Gateway 18.37.35.162
P2 is connect to Remote Gateway's network 192.168.1.0/24 (this is Site A's subnet)
For additional 2nd P2, what network should I put in?

Site A IP 18.37.35.162, subnet is 192.168.1.0/24:
Tunnel A <-> B:
P1 is connect to Remote Gateway 28.37.35.162
P2 is connect to Remote Gateway's network 192.168.2.0/24 (this is Site A's subnet)
For additional 2nd P2, what network should I put in?

Site C IP 38.37.35.162, subnet is 192.168.3.0/24:
Tunnel C <-> B:
P1 is connect to Remote Gateway 28.37.35.162
P2 is connect to Remote Gateway's network 192.168.2.0/24 (this is Site A's subnet)
For additional 2nd P2, what network should I put in?

@keyser said in IPsec Logging levels can no longer be changed..:

@jimp Hi Jimp. thanks for the insight and analysis. Will there be a patch for this in the patch tool?

Yes, eventually, might be next week or later, but you can add in a manual entry now (copy/paste that diff above) and apply it now if you don't want to wait.

@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.

@NOCling hello friend.

Thanks for helping me. Your information about MSS with 1328 solved my problem.

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?