I don't know what is happening on the other side. I will ask the remote side network administrator. There is same configurations on both sides. What could be the problem in your opinion?

@timmzahn said in IPSec Down after Upgrade to 2.3: ou ever find a more elegant solution to the issue, or are you sti I know this topic is old, but since I found it via google I will post my solution. I did replace OpenBGP with FrrBGP. I have been able to restore my IPSEC tunneling with AWS and also use the BGP services on PfSense for my needs.

That would be information I would expect to be provided. If not, then that's OP's problem and will only delay assistance.

That is either Status > IPsec or the IPsec dashboard widget querying the status of the IPsec process. Yes, it's normal.

Bummer, it does add a noticeable amount of throughput on my line, which is bandwidth limited and has a monthly data cap. Still, with the preference setting turned into a no-op, did anyone actually try if it would work? There have been substantial changes in the underlying software, that it may work, after all, in a time long ago, it used to work fine, too.

@roofus Actually is the best option

@Derelict Here is the configuration on pfSense 2 [image: 1536655424267-df519efa-fcf2-4e62-bf5b-b8a6eb0bb586-image-resized.png] And the route installed when IPSec tunnel established: [image: 1536655346631-dd01880e-a2c7-45fc-99ec-37120a8fc244-image-resized.png] [image: 1536655208710-e03a4e29-caf4-4b6a-a939-cd070be93969-image-resized.png]

Awesome. Please post back if you see continuing issues.

I tried somethings but the L2TP never worked on a second client in same remote site (same Public IP)... I see the IPSEC connexion but I'm rejected, seems in L2TP...

Ah, should have thought about LAN bypass. Oh well. In the end I went and renumbered everything out of 10.40/16 and into another Class C 192.168.201.0/24. I am looking forward to 2.4.4. however, routed IPSEC sounds like the real solution. This is how the Juniper SRX on the other end handled things. Creates and extra interface and you simply route down that interface. Thanks again for the input it is appreciated.

I don't recall the history there specifically. I'm not familiar with that plugin myself. In the past, however, there were a number of strongSwan plugins that were not supported on FreeBSD or did not work properly there. It would not surprise me to find that was the case here, or that SPDs behaved in a more consistent and predictable manner.

So this worked brilliantly! Thank you so much.

Try OpenVPN for B-C, it runs pure UDP or TCP, so can work when the provider is blocking other protocols. You should be able to add the C subnet to the B-A phase2 and vise versa.

You need to add Phase 2 entries to cover the traffic between 192.168.16.X and 10.0.0.X. Those need to be on both tunnels. Steve

https://www.synology.com/en-us/knowledgebase/SRM/tutorial/VPN/How_to_set_up_Site_to_Site_VPN_between_Synology_Router_and_UniFi_SG Based on the article above, the settings below seem to be stable on both sides so far Phase 1: Encryption: AES128 Authentication: SHA1 Key life: 14400 DH Group: 14 (modp 2048) DPD (Dead Peer Detection): disable Phase 2: Encryption: AES128 Authentication: SHA1 Key life: 14400 DH Group: 14 (modp 2048) The only thing on the USG side is selecting Enable Perfect Forward Secrecy (PFS) checkbox. Update Been up for 19 hours solid

I noticed how the official guide says "Users have reported issues with Windows L2TP/IPsec clients behind NAT. If the clients will be behind NAT, Windows clients will most likely not function. Consider an IKEv2 implementation instead." Wouldn't that almost always be the case, aren't the vast majority of home networks running nat by default? But doesn't look like a better option, as the guide mentions that mobile clients needs to download a third part vpn app. And you need to transfer ca files between clients.

Good day Folks, Walked everything through again to figure out what’s going wrong here. The remote subnet is 10.230.248.0/21. When I calculate this, the amount of host will be 2046. The host range will be 10.230.248.1 till 10.230.255.254. Correct me if I am wrong but 10.230.252.125 should be reachable as well, right? Very strange that I can ping and reach 10.230.252.114 but not 10.230.252.125? Again, when I am at work, 10.230.252.125 van be pinged and the webhost is reachable correctly. Does this make sense to anybody? Kind regard, Herman F.

Having a similar situation and wondering if you every resolved this, can't find much of any response or help for the issue on this forum. Established tunnel without issue to the AWS hosted PFSense from a sonic wall. Can watch the inbound pings hit the system but no progress from their or response.