Thank you Derelict,
this is ok when ASA terminates the tunnel, but why only after 30Min and not after 10Min as i set the tunnel?
And is it normal that pfsense sends the keep alive?

I recognized that the scenario desribed above is NOT possible without changing the Network on at least one side.

Reason: 1:1 NAT is necessary on both sides, but not available on Amazon side for hardware-VPN

As described here:
https://wiki.openwrt.org/doc/howto/vpn.ipsec.overlappingsubnets

Real Life Example

So what is it all about. Let us start with a picture and some explanations. What do we have?

ACME company with internal subnet 10.1.2.0/24 has an existing tunnel to another company with subnet 192.168.2.0/24. The firewall therefore will route all packets with destination 192.168.2.1-192.168.2.254 into the existing tunnel.
Our OpenWrt user at home has already a IPsec VPN connection too. The OpenWrt firewall protects his network 192.168.2.64/26 and routes all traffic to 10.1.0.0-10.1.3.254 towards the established tunnel to another company.
When establishing a new tunnel between home and ACME without address translation we would run into routing conflicts. E.g. if we want to reach the server 10.1.2.55 from home it could either be a machine in the ACME network or in the others company network.

What to do? Both firewall adminstrators have to choose IP address ranges for the new tunnel that do not overlap with the existing infrastructure. In our case:

The ACME administrator chooses to "hide" the remote home network behind the subnet 192.168.3.0/26. So when someone from ACME company wants to reach the newly conected home network he has to take on of those addresses instead of the real ones in range 192.168.2.64/26
The same applies for the home user. He does not want to reach the ACME network with its real IP addresses but changes the target range to 10.1.4.0/24.
That means each of both sides determines the remote part of the tunnel subnets.
Let us look at the packet flow and see where address translation has to occur. Let us assume we want to reach ACME mailserver on address 10.1.2.55 from our laptop with address 192.168.2.77.

We cannot use the mailservers real address but have to choose 10.1.4.55 instead. You can see that the lower part of the IP will match the original address while the higher is taken from the translated subnet.
The laptop sends a packet with header 192.168.2.77→10.1.4.55.
The OpenWrt firewall has to translate the source address into one that can safely pass the tunnel. Again it will only translate the higher digits. The header will become 192.168.3.11→10.1.4.55. If not sure why 2.77 is converted to 3.11 you just have to check the last bits of the home netmask …11000000. Only the last 6 bits will be retained.
The packet is sent into the tunnel.
When it reaches the ACME firewall it will be translated again. This time the destination address will be mapped over to the real addresses. The header will be changed to 192.168.3.11→10.1.2.55
The answer packet of the mailserver will travel this chain backwards.

And and Amazon:
https://aws.amazon.com/de/vpc/faqs/?nc1=h_ls

Q. How do I connect a VPC to my corporate datacenter?

Establishing a hardware VPN connection between your existing network and Amazon VPC allows you to interact with Amazon EC2 instances within a VPC as if they were within your existing network. AWS does not perform network address translation (NAT) on Amazon EC2 instances within a VPC accessed via a hardware VPN connection.

Two things solved the problem

as you mentioned there were some issues importing the key.  I imported into local machine into the proper container but that didn't work, I had to import it into personal as well, then I was able to get to the next problem

next problem was authentication, I was PSK and EAP, not sure how I missed that.

Not the tunnel works, but having other issues with the 10.0.0.0/8 subnetting.  If you can assist on that, that'd be great.

Network A (the pfsense box) has the following subnets
10.40.0.0/16
10.142.0.0/24
10.20.0.0/24

Network B (my client side) has the following subnets
172.16.0.0/16
10.205.0.0/16

When I set the mobile clients to 10.40.196.0/24 for a subnet the client side route the 10.0.0.0/8 via the tunnel which kills one of my local subnets on the network here from my workstation (since I have a 172.16.x.x address).

So logically I tried changing the mobile client to 192.168.168.0/24 and I can route on my side just fine but I have to manually add the routes to network A each time I connect as they aren't auto mapped.

Phase 2 on network A pfsense box does indeed had 3 entries with the proper subnets.

Anyway to auto map the route to the proper subnet?

It is generally better to just attach the image when posting using the attachment function there.

Otherwise use the insert image button in the editor toolbar.

Sometimes not working?

You are still providing nowhere close to the information needed to help you.

Your problem might very well be on the Barracuda side. Impossible to know.

What are the firewall rules on the IPsec tab? Post a screen shot.

Yep, that's it, as per this bug report:
https://redmine.pfsense.org/issues/6481
stop, then start, the reload doesn't cut it when going from EAP-MSCHAPv2 to EAP-RADIUS

Geocast had all the info, I should have looked at his whole post including the link to the bug report at the end.
I could not see IPSEC (Mobile IKEv2) client auth attempts comming through to my RADIUS Server at all. It worked perfectly with EAP-MSCHAPv2 and local users though….
Testing from Diagnostics  > Authentication  always worked and so did RADIUS auth with OpenVPN so I knew that NPS was set up correctly.
2-3 hours later it all came down to a tiny niggling bug taken from the link at the bottom of Geocasts post:

https://redmine.pfsense.org/issues/6481

Updated by Chris Buechler 4 months ago

happened to encounter this with a support customer today. It appears a reload of strongswan doesn't correctly enable EAP_RADIUS, you have to restart or stop then start.

Adam: if you reboot, or stop then start strongswan, does that work?

#2  Updated by Randy Snow 3 months ago

I wanted to jump in to say I just had this same issue on 2.3.2 today. Same log message and everything. Confirming you actually have to stop the process and then start it back up. The restart in the pfsense gui did not appear to remedy the issue.

OP wasn't mine it was ptclabs, but thanks for the info. I will give it a try again on a fresh config.

udp/500, udp/4500, and all ESP traffic.

At the moment there is no way to enter that directly. If the sonicwall side supports Dynamic DNS along with WAN failover you can enter the hostname on pfSense as the peer address. For that to work, the sonicwall side would have to update its address in DNS when the WAN switches, and then pfSense will see the DNS result change and update the IPsec tunnel to follow.

The problem is solved! I found the solution here:

https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

Thank you kindly. I had the Version set to auto (ASA set to IKEv2) so it wasn't appearing. Trying to debug some L2L ipsec issues currently with multiple child SA.

2.1.4? Upgrade and ask again.

That's exactly what it was. ASA does not support sending multiple SAs in the same TS payload.