You will need to provide much more information about your IPsec configuration, including which client you used or how you configured the native client. For Windows 8+, the doc wiki article on using IKEv2 with EAP-MSCHAPv2 is likely the best choice for using IPsec built into Windows. Be sure to follow the setup exactly.

i'm not sure, is it possible that the } - char is missing in the charon section of /var/etc/ipsec/strongswan.conf so that (prob.) the setting becomes invalid?  

That's generally not something you'll find outside of Cisco devices. It's not good to tunnel over TCP anyway, stick with UDP.

Everyone, Thank you very much for your help! My understanding is that this https://forum.pfsense.org/index.php?topic=99477.0 post discusses the same type of issue. In the second post, Derelict says that you can 1:1 NAT map the remote LAN, and present their remote subnet as something else: As far as I know, at least one of the SonicWALLs will have to 1:1 NAT their LAN and present it as something else so pfSense doesn't have two routes to the same subnet. If the client does this (or remaps the subnet) we should have no conflicts with the other two subnets, correct? Are there any other avenues/solutions to make a broad change to a large range of IP addresses on a subnet? Thanks again!

Anyone at all have any suggestions? I need to Get the public IP from the cisco unit presented by the pfsense box for VPN connectivity Configure a way for the private IP to connect to the remote sites

Thank you very much for that information. What is slightly more confusing to me is why the order of the definitions in the ipsec.conf file should affect the operation of the links. I am still investigate this and a few other issues relating to the VPNs and I will report back once I have some solid information. Unfortunately, I only get limited time each week to look into these problems. I am observing what is well documented as a memory leak in charon. I am assuming this will eventually be resolved. I am observing some strange NAT issues with the VPNs. At this stage I am just working around these problems. I am investigating a strange issue where VPN tunnels stop passing traffic and then mysteriously start again when a new TCP session opens via the same tunnel. I am investigating the issue with the order of the IPsec definitions and why this should alter the behaviour of the VPN system as a whole. As I said, thank you for the response it will be very useful. Also thanks for the work on pfsense - it is a great product. If I can get the IPsec working reliably it will be a perfect product! Tim

@cmb: The difference is whether or not it has multiple traffic selectors on a single child SA. Which, as responder, will be dependent on what the other end is doing. What is the other end? Sonicwall, don't know exactly what type as I don't control the other end.

Now, I have a stable IPsec tunnel, but i can't reach any client on the remote side. I get the following logs: Sep 20 21:18:08 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:18:08 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:18:08 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:18:08 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:18:08 charon: 15[ENC] <con1000|1>parsed INFORMATIONAL_V1 request 3846293289 [ HASH N((30)) ] Sep 20 21:18:08 charon: 15[NET] <con1000|1>received packet: from 81.217.23.223[500] to 193.81.148.115[500] (76 bytes) Sep 20 21:18:08 charon: 15[NET] <con1000|1>sending packet: from 193.81.148.115[500] to 81.217.23.223[500] (172 bytes) Sep 20 21:18:08 charon: 15[IKE] <con1000|1>sending retransmit 1 of response message ID 3559683763, seq 5 Sep 20 21:18:08 charon: 15[IKE] <con1000|1>sending retransmit 1 of response message ID 3559683763, seq 5 Sep 20 21:18:04 charon: 08[NET] <con1000|1>sending packet: from 193.81.148.115[500] to 81.217.23.223[500] (172 bytes) Sep 20 21:18:04 charon: 08[ENC] <con1000|1>generating QUICK_MODE response 3559683763 [ HASH SA No ID ID ] Sep 20 21:18:04 charon: 08[IKE] <con1000|1>received 28800s lifetime, configured 0s Sep 20 21:18:04 charon: 08[IKE] <con1000|1>received 28800s lifetime, configured 0s Sep 20 21:18:04 charon: 08[ENC] <con1000|1>parsed QUICK_MODE request 3559683763 [ HASH SA No ID ID ] Sep 20 21:18:04 charon: 08[NET] <con1000|1>received packet: from 81.217.23.223[500] to 193.81.148.115[500] (204 bytes) Sep 20 21:17:59 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:17:59 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:17:59 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:17:59 charon: 15[IKE] <con1000|1>received (30) error notify Sep 20 21:17:59 charon: 15[ENC] <con1000|1>parsed INFORMATIONAL_V1 request 3122718413 [ HASH N((30)) ] Sep 20 21:17:59 charon: 15[NET] <con1000|1>received packet: from 81.217.23.223[500] to 193.81.148.115[500] (76 bytes) Sep 20 21:17:59 charon: 15[NET] <con1000|1>sending packet: from 193.81.148.115[500] to 81.217.23.223[500] (172 bytes) Sep 20 21:17:59 charon: 15[IKE] <con1000|1>sending retransmit 1 of response message ID 3922146324, seq 4 Sep 20 21:17:59 charon: 15[IKE] <con1000|1>sending retransmit 1 of response message ID 3922146324, seq 4 Sep 20 21:17:54 charon: 15[NET] <con1000|1>sending packet: from 193.81.148.115[500] to 81.217.23.223[500] (172 bytes) Sep 20 21:17:54 charon: 15[ENC] <con1000|1>generating QUICK_MODE response 3922146324 [ HASH SA No ID ID ] Sep 20 21:17:54 charon: 15[IKE] <con1000|1>received 28800s lifetime, configured 0s Sep 20 21:17:54 charon: 15[IKE] <con1000|1>received 28800s lifetime, configured 0s Sep 20 21:17:54 charon: 15[ENC] <con1000|1>parsed QUICK_MODE request 3922146324 [ HASH SA No ID ID ] Sep 20 21:17:54 charon: 15[NET] <con1000|1>received packet: from 81.217.23.223[500] to 193.81.148.115[500] (204 bytes) Sep 20 21:17:54 charon: 15[NET] <con1000|1>sending packet: from 193.81.148.115[500] to 81.217.23.223[500] (76 bytes) Sep 20 21:17:54 charon: 15[ENC] <con1000|1>generating ID_PROT response 0 [ ID HASH ] Sep 20 21:17:54 charon: 15[IKE] <con1000|1>IKE_SA con1000[1] established between 193.81.148.115[193.81.148.115]...81.217.23.223[81.217.23.223] Sep 20 21:17:54 charon: 15[IKE] <con1000|1>IKE_SA con1000[1] established between 193.81.148.115[193.81.148.115]...81.217.23.223[81.217.23.223]</con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1></con1000|1> Thanks! Thomas

@Gob: I vaguely remember we built this unit originally with v 2.2 BETA and restore the 2.1.5 IPSEC config to it so that may be the source of the problem. It seemed to be tunnels that had multiple phase two entries. I have put it down to importing into the Beta version. Yeah that makes sense. There was a period in 2.2-BETA where the config upgrade didn't happen correctly especially with multiple P2s, so that explains it. Thanks

Thanks for clearing that up for me. It steered me into the phase 2 configuration. Which included a /24 subnet specifucation on a network adres ending with an actual IP. (254 instead of 0) This however did not fix the problem. The whole thing is rather complex since it's a combination of Firewall and VPN boxes in an Azure network. The Azure fabric has it's own networking properties. I didn't mention this before because I wanted my question about routing over IPsec to be clear and understand the behavior. I fiddled around a little bit with static or DHCP on Azure on the VPN box and ruined it. Rebuild the setup and decided to exclude the remote side out of the equation by setting up 2 VNET's on Azure and rebuild the entire scenario without the inherited config of Side B (non-azure). It's worked straight away. So then I setup VPN connections to Side B on both the Azure test Vnets. Same problem in both the Azure boxes, so problem was originating from Side B. First thing I did was create floating rules to allow ICMP from all internal networks. That didn't fix it. Then I set those allow rules to "Quick" to be allowed straight on being matched. This also didnt fix the problem. Then I realized the Ping had to come from one of the internal nics and I specified the LAN interface as the "from" network on the webinterface. This resolved the situation on Side B. Now it's possible to ping the LAN interfaces of all VPN routers. I've spend a lot of time thinking it was somehow connected to the VPN config, while actually it was firewall logic blocking the traffic. Side B is a box that had a year uptime until I updated it this week because I couldn't get the VPN working on the old version. Inherited config made it very hard to understand and fix this problem. I ended up looking in the wrong place and spending a lot of time with that. Hopefully someone is helped with fiddling efforts Thanks for the community support and the refresh of my networking logics. The rules that apply in this field are very specific. A structured approach to troubleshooting is the way to go. Thanks again

That isn't enough log context to tell whether it's rekeying or what's happening. The only thing that shows definitively is the remote end is telling your end to delete the SA. Might be because it's rekeyed, or its lifetime expired, or the SA was deleted manually on the remote end, among other possibilities. What logs surround that?

Thank you all for the assistance.  I did change the subnet on one of the branch offices and all went smooth after that. Thanks.  :)

Yeah that's pretty much what I suspect is happening but was hoping someone had found a work-around.

Likely just need to enable MSS clamping on the advanced tab.