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 Local subnet LAN -> 172.18.2.0/23 OPT/DMZ -> 172.18.2.0/23 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…

FWIW, I've spent many hours trying to get a reliable VPN between PFSense 2.2.1 and a Draytek with IPSEC. Draytek to Draytek works fine but the PFSense VPN drops out and/or fires up multiple Phase 2's after which traffic doesn't flow :( I've tried setting the Draktek as outgoing only/incoming and both and tried telling PFSense to only be a responder. No difference. I'd love to know what the trick is.

I am seeing this as well, however I didn't realize that was the problem and was digging into the IPSec connection settings until I ran across this post, stopping and starting IPSec services, etc, reloading the filter is the fix. I haven't figured out anything more on why yet, but now that I know its a filter issue and not an IPSec issue. I at least know where to look now.

Good that it works now. ;)

@kodimar: My research has pointed that the NO_PROPOSAL_CHOSEN error is caused by an error in the Phase 2 settings.  Is this a correct assumption? It can be either Phase 1 or Phase 2. See https://doc.pfsense.org/index.php/IPsec_Troubleshooting for help interpreting the logs. Best thing to do is set IKE SA, IKE Child SA, and Configuration Backend to Diag in the log settings, all others on Control, and have the remote end initiate.

Ok so I do understand the basics of setkey after I have been reading up on this all day. But I can't seem to add any entries. It doesn't matter what I type into the command line the only response I get is: setkey: No match. I am trying to setup the captive portal on the OPT1 interface, but because the interface is not reachable because I have an IPSec tunnel from the interface the captive portal does not work. My interface is IP: 10.11.15.1/24 Could someone please help me out with the command for setkey? Thanks

yes, there I created a any-any-any rule so it's not blocked by firewall (normally) When I start debug on te SRX side I see that traffic is going into the tunnel, but not coming out on other side :-)

now I check the Virtual IP bug look the responder only mode and all other points from this Post on last Days. I have no clue what ist wong after the update to 2.2.1 always wrong remote address ??? Thanks for your Help