IPsec is dial-on-demand essentially, it won't come up until you send traffic matching a phase 2 to trigger it. That's why the keepalive IP exists in phase 2 entries, where the firewall has a local IP configured on the IPsec connection, it'll use it as the source to ping the remote IP defined in the P2 which will trigger negotiation of the VPN (doesn't matter whether the ping gets replies) to keep it connected all the time.

It's checking the output of setkey -D and setkey -DP and correlating the output with the defined tunnels. Check /etc/inc/ipsec.inc and look at the Phase 1 and Phase 2 status code.

Solved.

Add a Phase 2 entry on both sides that covers the path from Site B's LAN to the IP address or subnet of the web site. Then make sure Site A's outbound NAT rules cover the LAN subnet at Site B.

Has anyone seen this error? racoon: ERROR: 45421:error:26078067:engine routines:ENGINE_LIST_ADD:conflicting engine id:eng_list.c:116: 45421:error:2606906E:engine routines:ENGINE_add:internal list error:eng_list.c:288: I haven't been in my site B yet to change parameters, but I notice site B is trying to connect with Site A.  I get… racoon: [Site B]: INFO: initiate new phase 1 negotiation: aaa.aaa.aaa.aaa[500]<=>bbb.bbb.bbb.bbb[500] racoon: INFO: begin Aggressive mode. racoon: ERROR: 45421:error:26078067:engine routines:ENGINE_LIST_ADD:conflicting engine id:eng_list.c:116: 45421:error:2606906E:engine routines:ENGINE_add:internal list error:eng_list.c:288: racoon: ERROR: failed to get subjectAltName racoon: INFO: received broken Microsoft ID: FRAGMENTATION racoon: INFO: received Vendor ID: DPD racoon: ERROR: no peer's CERT payload found. I'm guessing the first error is a result of my certs being different and possibly my CAs being different as well.  If this is really the case, it makes me wonder what the real differences between RSA and PSK are.  It strikes me that they're the same thing with the exception that RSA is managed by a CA and PSK you can define whatever key you want (even as long and complicated as a cert). I'm not sure if the subsequent errors are related to the engine failure or something different.  I did find this which indicates that racoon is looking for a subjectAltName whether it uses it or not… http://verb.bz/2008/12/02/racoon-requires-subjectaltname-for-x509-ike/ Any thoughts and/or input appreciated. Thanks.

@pieterraxis: Hi, Did you figure it out to increase performance? I have the same problem! And i am using  aes 128 cbc What does RNG mean in this line? $ dmesg | grep AES glxsb0: <amd geode="" lx="" security="" block="" (aes-128-cbc,="" rng)="">mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0</amd>

well I am not exactly sure how. But I managed to get all 3 tunnels up and running. I was doing a few different things. Clearing out SAD's, deleted  some SPD's. Checked the SPI's were matching with my connecting firewall and the like. So I am not sure what it was I did that made the tunnels come up, but they seem to be up in my test environment at least. I would still like to understand why the tunnels take so long to come up sometimes if someone could help with that.

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