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

Have you enabled the CISCO unity feature? - I think Chris had made a comment about this already. You don't see this traffic when you do a packet capture on your interfaces directly from pfsense?

Haven't yet worked this out… Any ideas why the reply to the initial FTP request has a source IP of the physical IP on my WAN Interface?  To the internet, the ISP NATs this to a global IP, but this isn't relevant I believe State of this reply: WAN -- tcp -- <wan ip="">:42390 --> <remote ftp="" server="" ip="" across="" vpn="">:21 -- SYN_SENT:CLOSED</remote></wan>

@cmb: That doesn't match the P2 you have defined, so it's not supposed to go over the VPN. Needs to be source of the network, not single IP, like your other one. I'm not quite sure what you mean. The given configuration is mandatory by the provider of the tunnel endpoint… It works using the same config on another router like a Draytek!

well and i dont know for exactly sure they are ALIX, but they are older red netgate units with 3 interfaces.  but they do keep repeatedly dropping their ipsec tunnels every day, and i constantly have to log into them and restart the tunnels. i did have 2 even older and smaller silver netgate's whcih both did not survive the 2.3.x upgrade.  one died and woudlnt reboot, one repeatedly said corrupt update file.  replace them both with brand new units. the rest of the history on this project is, previous consultancy deployed all these netgate units and used openvpn back to HQ (and never updated them).  old consultants were out out and i was in, their HQ moved to a new location/IP, so all these firewalls were left on their on for a few months (no VPN). when i finally get around to them and update them to 2.3.x and build IPsec tunnels back to HQ, now the tunnels (and often the internet as well) keep going up and down.  as the customer does not have any technical people working for them full time, all they see if firewalls that dont stay up after i upgraded/VPN'd them all. so right now im grasping at straws trying to figure out whats wrong.  i have SO many other pfsense installs out in the field (all newer PCs or newer pfsense hardware) and these dinosaurs are the only ones giving me troubles.  but there are about 50% of the netgates that fall into the same age group that are working 100% fine.

A clean install with 2.3.1 and a quick setup of the ipsec site-to-site, came up straight away. I played with the IKE settings between Auto, v2 and v1 - As cmb said,  my config must have been different when I was comparing. Thanks…

Also, FYI- If you choose to use AES-GCM in P1 for an IKEv2 tunnel, use AES-XCBC for the "hash" algorithm (really it's a PRF in that case and not a hash…).