Confirmed this is fixed in 23.09.1-RELEASE

@keyser let me start by saying that I appreciate the time you're putting into this. Right now, it's just a matter of curiosity but it bugs me to the core as I don't know why it needs MSS clamping all of the sudden.
Now, I've ran the test and captured the packets (see the attached pcap files) but I am unable to determine why it's working / not working. I've included two pcaps, one with the non-working HTTPS connection, one with the working one. From my point of view (I'm sure I'm missing something), it doesn't look like an issue. I don't know why all the retransmissions in the non-working but as I said, I'm probably missing something.

P.S. 10.41.199.205 is the HTTPS server, 172.31.254.251 is the client.

Thank you.
working.pcap non-working.pcap

SNAT and DNAT is all you need here. Either site won’t know the real IP but that’s ok obviously you will keep track but that’s all that’s needed here to get around the overlap

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?

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.