Last bump, I was able to resolve this, so I figured I'd leave the solution in case it helps anyone else in the future. The issue, as suspected, was routing:  packets didn't know, once they left the office through ipsec, how to get back.  I needed to go back into the ipsec setup and pass the new OpenVPN virtual tunnel subnet through as additional phase2 entries.  Once I did this, everything started working smoothly, and we no longer have problems.

It means you have a settings mismatch. The other side is attempting to inform you of that but it's sending a message in a format that racoon can't interpret.

Ok, that looks like it corrected the core dump issue at least, though I'm having no luck with getting my Android phone connected.  I don't know where to look from there. I used the mobile client tutorial to no avail, but I'm not sure which end is not working correctly now, but that's likely for another topic.

Me responding to myself again. ;-) Could please someone give me an answer why I didn't get any response? Stupid Question? (I don't think so) Not enough information given? Everyone assuming me to be unable to check for similar entries on both sides of the tunnel? I assume noone had any idea. Well I was hoping for advice of some experienced users / admins here…. Nonetheless I fixed it finally by reinstalling one PfSense Box (the "Static" one) after it gave me an error every time i tried to save the Phase 1 Settings. (Acknowledge All Notices -Date- [ pfSense is restoring the configuration /cf/conf/backup/config-1391473112.xml] ) Restoring my backed-up configuration led to the same error, so I installed again from scratch. ;-) (Hope no neighbour heard me…) Turned out that the "restoring configuration" error at saving the Phase 1 settings seems to be a reproduceble bug, when a german umlaut (ß, ü, ä ...) is used in the PSK.  https://redmine.pfsense.org/issues/3401 (NOT used initially, just used later to have an "easy to type key") The 2 PfSenses are working together now with the settings Fritzbox needs. Still the reconnecting issue though, which seems to be fixed in 2.1.1 prerelease. https://redmine.pfsense.org/issues/3321 I don't expect any errors connecting the Fritzbox tomorrow. Conclusion: 1.: There must have been a bug in the installation / configuration that produced the initial problem without any errors in the logfiles and was resolved by reinstalling. Restoring the configuration should have worked, it just restored the faulty characters too. ;-) 2.: If there is a bug in any Software I use, I,ll run into it. Karma. 3.: Don't try to get help in Internet Forums, if the solution is not already posted. CU itsol

Unchecking that does change the output.  Unfortunately, it now appears to be defaulting to the 1st VPN for all subsequent entries.

Ok I tracked down and solved one huge problem I was experiencing :) and have now found a new one.  :( It turns out there is a nasty bug in the built-in Apple iPhone iOS 7.0.4 IPSec client. I had started off with (standard) Racoon in Ubuntu, and then tried pfSense both configured to PSK, and therefore had of course also started off with the iPhone and its IPSec client also configured to a PSK. When I reconfigured Racoon and pfSense to use Certificates I of course reconfigured the iPhone to match. I did not however delete the existing profile on the iPhone I merely modified it. This should have been fine, however it turns out the iPhone was still sending the Group Name to the IPSec server and this was certainly giving pfSense indegestion. Note: I spotted this in the logs for StrongSwan, no entry in the Racoon logs suggested this. I had started to move on to testing StrongSwan since I had been unsuccessful with pfSense and Racoon. Once I made a fresh profile on the iPhone I was then able to successfully make IPSec with certificate connections from the iPhone to pfSense. So that is the good news. Unfortunately I still have a problem. I am wanting to route all traffic via the VPN connection, this works for IPSec with no certificates and is achieved by not ticking the option in pfSense to 'Provide a list of networks to clients'. If however with certificates I have this option unticked then the connection fails with the following errors in the log. Feb 3 15:47:31  racoon: [Self]: INFO: respond new phase 2 negotiation: 81.x.x.12[500]<=>86.x.x.247[500] Feb 3 15:47:31  racoon: ERROR: failed to get sainfo. Feb 3 15:47:31  racoon: ERROR: failed to get sainfo. Feb 3 15:47:31  racoon: [86.x.x.247] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1). With that option ticked it works fine but of course means that only traffic for the LAN gets routed via the VPN connection. I did also notice that there maybe a Phase2 mismatch between the client and the server. The pfSense server is configured to use a virtual IP range of 10.0.1.0/24 for clients. However when the iPhone connects I get the following message in the log. racoon: INFO: no policy found, try to generate the policy : 10.0.1.1/32[0] 192.168.16.0/24[0] proto=any dir=in As you can see it is listing the policy as 10.0.1.1/32 and not as expected 10.0.1.1/24. Although from on point of view the fact that there will only be a single device at the client end makes a subnet mask of 32 logical. This does mean however that if I set the IPSec Tunnel proposal checking to anything other than Obey it fails due to a mis-match between the client and server ends. The full set of log entries for this type of failure looks like Feb 3 15:58:41  racoon: [Self]: INFO: respond new phase 2 negotiation: 81.x.x.12[500]<=>86.x.x.247[500] Feb 3 15:58:41  racoon: INFO: no policy found, try to generate the policy : 10.0.1.1/32[0] 192.168.16.0/24[0] proto=any dir=in Feb 3 15:58:41  racoon: ERROR: pfs group mismatched: my:2 peer:0 Feb 3 15:58:41  racoon: ERROR: not matched Feb 3 15:58:41  racoon: ERROR: no suitable policy found. Feb 3 15:58:41  racoon: [86.x.x.247] ERROR: no proposal chosen [Check Phase 2 settings, algorithm]. Feb 3 15:58:41  racoon: [86.x.x.247] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1). There is of course no-way to configure this on the iPhone. So I am now very close. I can do IPSec with PSK+Xauth for LDAP and route all traffic, I can do IPSec with RSA+Xauth for LDAP but cannot route all traffic. Has anyone been able to do IPSec with RSA+Xauth and route all traffic with an iPhone?

Not currently, no. That may change on 2.2.

If it is a remote firewall, why are you using mobile to connect? It should be a normal site-to-site tunnel, not mobile. That hasn't really been supported since 1.2.x and even then it didn't work well. Use a normal tunnel + dyndns if the remote has a dynamic IP. Don't use mobile for site-to-site.

That is not currently possible if you go by IP address. If you can track it with dyndns, and the DNS record changes when the far side IP changes, that would work. It's not possible to put two peer IPs on the tunnel though so outbound failover wouldn't work that way either.

Hi, if both boxes are identical maybe the environments are not. How much CPU usage do you have at idle and while performing the speed test (on both sites)? Given you never reach line speed I suspect you hit 100% CPU usage.

Your local subnet looks like 169.254.255.82/30. Per RFC 3927 this is a link local address which is not routable. Your remote subnet looks like 169.254.255.81/30. This is again link local, and on the same subnet of the local address. IPSec is supposed to connect two different subnets. What is your local LAN? What is your remote LAN (AWS)?