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

Setup instructions for Windows IKEv2:
https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

You don't need to disable it, just don't edit a P2 on your mobile P1 and expect it to work for site to site. Add a new P1 for the site to site.

Consider you should be sending the magic packets to the the broadcast address of the subnet (so you make sure it is put on every wire and the NIC receives it). Sending directly to the IP you want to wake up usually does not work because the ARP cache entry is most certainly cleared by the time you want to wake the PC up

You could try out this two HowTo´s from the pfSense Document section!
IPsec for road warriors in PfSense 2.0.1 with PSK in stead of xauth
IPsec Road Warrior/Mobile Client How-To

@Trinity99:

Any idea why this particular connection is so slow?

Likely the great firewall of China. They drop a lot of encrypted traffic. You may or may not be able to keep a VPN up to there with any degree of reliability without jumping through hoops.

The MSS clamping suggestion is worth trying at least, but the fact you're dropping pings inside the tunnel and not outside proves that's not the only problem as pings are small enough that they won't encounter any such issues.

Draytek seems to be a popular choice for that role, though there are not many other vendors in that area with IPsec support that are of any quality to speak of.

Given how frequently I've seen lightning fry modems, I would never consider placing any significant sum into a device plugged into a telco network directly. Put a cheap bridged modem in front of a better router and you'll be much better off in the long run.

I haven't done this since pfsense 1.2.3 but you should be able to run two pfsense in a carp setup, and if you point your IPsec tunnel to the shared carp WAN ip it should work. I don't see any reason you wouldn't be able to do this on both sides.

I want to do the same thing along with streaming from the Steam in home streaming feature on my PC. From what I have gathered is that the steam streaming is enabled up by a UDP broadcast packet. https://codingrange.com/blog/steam-in-home-streaming-discovery-protocol

Since the IPSEC VPN tunnel is on a separate broadcast domain then this packet isn't being sent back/forth from LAN to VPN. Xbox streaming might work the same way?

I think this can be fixed by enabling forecast from within strongswan.

https://wiki.strongswan.org/projects/strongswan/wiki/Forecast

I however don't have the technical know how to make this happen or if it is even possible on FreeBSD. Hopefully a pfsense guru can enlighten us on how to configure broadcast packets to our IPSEC VPN tunnels.

We also experience this issue. We have approximately 50 tunnels and every two weeks or so I have to reboot the firewall because of this problem.