fixed it with auto ping host in advanced options in Phase 2. thanks!

Things got worse.  Racoon failed to even attempt to connect.  Specifically, hitting the connect icon returned immediately and there was no record of any connection attempt in the log. Deleted the phase one and phase two entries, and re-entering them.  Seems to be working now.

Must have been some sort of corruption in the configuration.

It might work if you bind the mobile IPsec to the LAN address of the far side, but I wouldn't hold my breath. You're bound to get into some … interesting routing with UDP and ESP. It might work, it may not.

Looks like I had a similar problem, after a cabel disconnect from ISP side (powerloss of cable booster) the tunnel didn't come up.
Checked dyndns and restarted both racoons, but did not help…
The I clicked release on the WAN and connect after that and suddenly all tunnels where back !

NO-PROPOSAL-CHOSEN means the remote end is telling you it has nothing matching your P1 settings. Many times a wrong local or remote IP for the outside of the tunnel. Could potentially be any number of things in the P1. Unless somehow it stops complaining about that and negotiates successfully, you're not getting to the point where dropping large packets across the VPN would matter. If you can't ping across at default ping sizes, that's not the issue.

can you show your fortigate firewall policy on ipsec and same with pfsenes ipsec policy

iOS log:
Jun  5 13:32:14 iPhone4 racoon[1248] <notice>: IPSec disconnecting from server 192.168.2.10
Jun  5 13:32:14 iPhone4 racoon[1248] <error>: failed to send vpn_control message: Broken pipe
Jun  5 13:32:14 iPhone4 racoon[1248] <warning>: glob found no matches for path "/var/run/racoon/*.conf"
Jun  5 13:32:14 iPhone4 racoon[1248] <notice>: IPSec disconnecting from server 192.168.2.10

I search error messages.
I find this site.

strongswan.org Wiki
http://wiki.strongswan.org/issues/290
http://wiki.strongswan.org/issues/596

Is this an Apple bug?
Thanks!</notice></warning></error></notice>

Update:

Just a change on the mobile clients page … Apply .... Error like above

Do another change on some item on the tunnels page .... Apply .... Everything ok. Also the change on the mobile clients page is saved

Replying to own post as this may help someone else in the future.

I found the issue.

On the remote side, I had defined our three (local) networks:

192.168.0.0/24
192.168.3.0/24
10.1.1.0/24

Because we had no need for the 10.x subnet to use the VPN yet, I didn't define a phase 2 entry on pfSense.

This was causing the errors.

Defining a phase 2 entry for the 10.x network on pfSense resolved my issue.

It's a known/expected issue.

You're probably already on manual outbound NAT. Add a rule there to NAT out LAN from the remote IPsec subnet source to a destination of the secondary's LAN IP address, translated to 'interface address'. Add another with a destination of the primary's LAN IP address (or use an alias and one rule).

That way when you try to reach the secondary it appears to originate from the primary and vice versa, avoiding the VPN knowledge issue on the secondary.

I kind of had the same issue with similar setup

Until now I had an IPSec tunnel configured to listen to interface "WAN_A" which was the only one available.
We added more connection (multi-WAN) and WAN_A is not the "Default gateway" anymore.

By looking at client-side tcpdumps and pfSense logs I can tell the client can send traffic to pfSense (show on IPSec logs) but never receives anything back (confirmed by IPSec logs: "racoon: [CLIENT_IP] INFO: DPD: remote (ISAKMP-SA spi=58…:71...) seems to be dead.").

In the future I might add more IPSec tunnel and they might not all listen to interface/gateway "WAN_A".

jimp, suggested to:

Use "LAN" as Interface for tunnel(s)

Set any desired identifier: I used "Distinguished name" setting and typed a pseudo domain name: vpn1.mycompany.com

Add NAT rules so that traffic incoming from WAN_A (and any other desired gateway) on ports ISAKMP (udp/500), ESP (ip/50) and NAT-T (udp/4500) goes to pfSense's LAN inteface IP: You have to manually type it there (can't select "LAN address")

Apply rules and restart IPSec service

I can confirm this works just fine: the same tunnel can now be contacted from any gateway (use NAT or firewall rules to filter out).

Finally got it resolved. It was being caused by a dodgy network card. Replaced the card and all is good now

@dotdash:

You should be able to go to VPN, IPSec, edit the primary connection and check the box to disable the phase1. If the backup connection is disabled, enable it. The last time I played with AWS, which was a while ago, you could have both connections active and setup BGP, but it would not failover automatically due to the tunnel trumping the routing table.

This worked perfectly, and the fialover worked flawlessly, to boot!  Thanks for the assist and the peace of mind it has brought!

Some more information:

This is not related to Racoon. I have enabled SSH for remote access, and I see exactly the same. The packets come in on the correct interface, but the replies go out on the interface with the default route, although the source address is the correct one (of the interface they came in to). If I manually add a route to the remote destination via the correct (non-default) gateway, then the replies go out on the correct interface. The conclusion is that the system does not reply via the same interface that the packet came through.

Routed packets are processed just fine - the reply goes back on the correct interface, the one that has originally received the packet. Only local PFSENSE services are affected.

On 2.2 strongswan can handle that, but we don't have options in the GUI to do it. It's capable of pulling an IP and supporting various Cisco Unity features when acting as a client. Not sure if/when that might ever show up, it's not a very common requirement.

Changed tunnel back to openVPN, same problem, but only on this single computer… Changed to another network card - works, at least with openVPN, not willing to switch back to IPsec at that time... :o

@cmb:

ipsec-tools is gone from 2.2, so I would recommend testing the situation there (now using strongswan), and if there is any similar issue, bring it up on the 2.2 board here. I don't believe that's an issue there, but confirmation would be good.

I see no banner in 2.2, whether 'login banner' is ticked or not (shrewsoft client, banner did appear under 2.1).  Haven't looked into details yet.