thx!
Thought so, but wasn't sure!

OP's logs show 192.168.25.201 as an identifier, so I'm sure that's this:
https://doc.pfsense.org/index.php/Upgrade_Guide#Stricter_Phase_1_Identifier_Validation

@mooboynyc:

IDir 'myhost.mydomain.com' does not match to 'XX.YY.ZZ.WWW'

To resolve, I edited the IPsec configuration.  Under "Phase 1 proposal (Authentication)", change the "Peer Identifier" from "Peer IP Address" to "Distinguished Name" and enter the dynamic DNS name of the remote end.  I was able to establish a connection after this single change.

Ditto for that. It was mismatched to begin with, racoon would just fall back to the IP if the identifier didn't match and try that, hiding the fact things weren't actually correctly configured.

Dear all

I have solved my problem… just follow this instructions:
https://forum.pfsense.org/index.php?topic=57104.0

Thank you

I set up a OpenVPN connection to each of the remote sites.  Then if there issues with the IPSEC tunnel, I still have access to the other end and can start and stop the service there if required.

Hi,

This does appear to be a bug - how do I raise a bug report on this? (Redmine?)

-=david=-

Enabling MSS clamping (VPN>IPsec, Advanced tab) at 1400 is a good thing to try.

That's not possible without significant source code hacking.

The unity bug that was the source of OP's issue was fixed/worked around in 2.2.1. If you check the "disable unity" checkbox on the advanced tab, it'll prevent that from being an issue.

@zueri:

Is there any news on this? I've updated to 2.2.1 last week and am facing the same issues. Switch Mikrotik to passive helped but it is not realy a good solution for me (Mikrotik should be Initiator in my case).

That definitely sounds the same as OP's issue, disable unity.

When I came in the next morning, the tunnel was up and had been initiated by the remote side.

I'm thinking Phase1 lifetime expired sometime during the night, forcing the ASA to reinitiate the tunnel. 
I'm guessing if the other guy had just reset his side manually it would have come up.

The end result was: NAT-T disabled, DPD disabled, and Proposal checking 'Obey'.

Set up phase 1 and phase 2 correctly.
Kick out the Gatweay/routing because you won't be needing it!

Tried that but doesn't seem to work?
Only thing  I changed within the phase two was

Firewall1

Firewall2
-Local subnet LAN -> 172.18.6.0/23
-Local subnet LAN -> 172.18.66.0/24

Strange, but after a reboot (due to other changes) the tunnel came active!
So thx again! Think I made typos somewhere!

@doktornotor:

All I was commenting on is that the request to implement "option for the remote subnet" on mobile IPsec is just nonsense.

Other than that, I'd suggest moving to OpenVPN and forgetting about this overly complicated, error prone, poorly compatible and generally horribly buggy IPsec thing.

doktornotor,

My apologies, I did not pay attention to the specific quote to which you were commenting. I should have been more clear, that suggestion is not for Mobile IPsec.

@doktornotor:

Other than that, I'd suggest moving to OpenVPN and forgetting about this overly complicated, error prone, poorly compatible and generally horribly buggy IPsec thing.

I disagree with you assessment IPsec as a general practice. I do agree that OpenVPN is easier to setup and I have had less issues with it, but…

IPsec is commonly used for enterprises and while it is harder to setup, a measure of that that is really a pfSense issue. Other network appliances allow you to use "Aliases" in the phase 2 subnet fields so you do not have to manually create a p2 entry for each and every subnet to subnet mapping.

IPsec is more mature with a greater feature set. Once of the large ones for me is split-DNS. I make multipler VPN connections at times and when more than one has local only DNS then I can only get to internal sites for one of the connections. The splid-DNS solution was implemented in IPsec which solves this. Each connection provides a list of zones that are local and DNS requests for hosts on those zones are push over the appropriate tunnel and the rest are does through your systems default DNS path. The OpenVPN community does not seem to get the value of this, so unless the devs see past that, it will never have split-DNS.

I appreciate your comments and I apologize again for my confusion.

Thank you,

Rhongomiant

Posted too soon. Not sure if my search-fu just wasn't up to it or what, but eventually I found strongSwan issue 255 at https://wiki.strongswan.org/issues/255. On the Android side, delete anything you might have in the IPSec identifier field. On the pfSense side, I switched Key Exchange version to Auto and changed Negotiation mode to Main.

Look, you do not manually configure things via shell, end of story. If you have need for a feature that does not exist, then file a new feature request in Redmine - https://redmine.pfsense.org/projects/pfsense/

Thank You. That's the advice I needed. It works fine now.
I've never looked up the list of local interfaces after setting the CARP Addresses.
What a bad mistake…