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.

I wanted to come back and share what I have found.  I have been looking at this issue for the last few days and I have easily come across 20 posts sharing the link I provided above.  Each of these posts discusses getting the DHCP Relay to work with PFsense while using an IPSec tunnel.  One thread referenced here: https://forum.pfsense.org/index.php?topic=6932.0 States that ssheikh back in 2008 actually got this to work by providing a dummy route back toward the DHCP relay machine from the other end of the IPSec link, but I have not been able to reproduce this. Finally, in an effort to solve this, I submitted a support ticket.  In which I received the reply: I have discussed your case whit our engineers and what you are trying to do here simply dose not work within pfSense alone, to achive this you need to use the IP Helper and DHCP Relay on the switches not on pfSense as it do not manage to send the reply back to the client, however you can still use the IPSec tunnel on pfSense So unless someone has something to add here, this simply won't work at all.  HOWEVER…. I also found this thread: https://forum.pfsense.org/index.php?topic=57769.0 That apparently allows you to pull in another DHCP relay package.  This package will allow you to bind to an IP address on the local pfsense box.  I found another thread referencing this and saying it functions well.  So this might deserve some follow up if you are really interested in making this work.

I accomplish what you request, using WAN groups and dyndns.. I attach my configurations, hope this helps you        

Well this is sort of interesting. I didn't really need my full subnet at SITE A available to SITE C so I trimmed it down so that SITE C now has access to the same 6 IP's that SITE B has access to. Once I did that traffic routed for greater periods of time before disconnecting. Strangely, for the first day pinging SITE C from a Linux server at SITE A would allow a reconnect but it took 40-50 pings. Running a ping from one of my Win10 laptops would not allow a reconnect. I don't really think that's relevant, merely interesting. As before, when the traffic stops flowing, the tunnel shows as being still connected from both ends but pinging something on SITE C's LAN from SITE A fails. Pinging something at SITE A from SITE C results in a near immediate re-establishing of traffic. As one might expect, leaving a ping running between sites keeps everything working, but that feels more like a kludge than a solution. I'm really stumped. SITE A has a 25MB Cable connection, SITE B and SITE C both have 50MB duplex fiber connections from the same provider. I have two more sites to connect to SITE C. SITE D is a rural location with a barely functioning DSL but it has an IPSEC tunnel between it's Cisco and a separate Cisco at SITE C that has been completely trouble free for years. It will be upgraded to a pfSense appliance shortly and the tunnel re-established. SITE E has a cable line and a Cisco so I'm eager to see if I get a different result.

You probably need to re-enable Unity. https://doc.pfsense.org/index.php/Upgrade_Guide#Removed_features_that_are_disabled_on_upgrade thank you CMB