Did you allow traffic in on Firewall > Rules, IPsec tab?

When it comes to NAT, the sonicwall doesn't know about your actual internal network. So their tunnel P2 is built to the NAT network and on the sonicwall side when they try to ping the pfSense side, they ping the NAT network addresses instead.

Not resolved, so adopted another solution for the 2nd tunnel.

according to the WISP, it's is prefered alternative instead of the bridge mode, which gave i'm some problems

I'm still trying to solve this

I tried openvpn tunnel, same thing.

I finally fixed it using:

http://phil.lavin.me.uk/2013/04/how-to-disable-icmp-redirects-in-pfsense/

Thanks

When you are making a change to a server with dozens of tunnels in production, stopping and restarting IPsec because of a change made to one tunnel can be a real downer.

Same problem here, but I had to use OpenVPN until 2.3.2 before I could use 3DES.

gahh, I'm sorry to say, I think it's related to some errant Group Permissions.

I've removed and recreated the group (and reassigned permissions), and it now works.

You would create a separate P2 entry for each subnet you need to access.  Also verify that the firewall rules for IPSec are not blocking your traffic.

Do you see the traffic from clients leaving the WAN in a packet capture? Does that traffic have NAT applied?

Check the state table and see what the outgoing states look like for the traffic as well.

"Encryption domain" in Cisco-speak is a Phase 2 entry. Something in there must not match their side exactly.

Set your IPsec logging as shown under https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29 and see what shows up when the Cisco side tries to initiate the tunnel.

You can distribute a route for any network you like, just add it to the list on the main page of the quagga OSPF settings.

Your IPsec Phase 2 definitions will need to cover the additional possible local/remote network combinations though (unless you're using something like transport mode with GRE/GIF…)

Did you try the "dynamic dns" option in peer identifier?

IPsec has gotten nothing but better between 2.2 and 2.3.2.

The answers to what is ailing you lie in the configurations on both sides and the logs on both sides. It is impossible to make a recommendation without seeing those.

In VPN > IPsec, Advanced set all the logging to Control except IKE SA, IKE Child SA, and Configuration backend. Set those to Diag.

Then look at Status > System Logs, IPsec and match up the logs with a failure and see what it complained about.