I was able to fix it by unchecking Obtain Topology Automatically under Policy in the settings of the shrewsoft vpn client and adding my local subnet under remote network resource. I can ping 8.8.8.8 now but the intrenet traffic is not going thru the tunnel.  :(

It knows the CA by which cert you pick, no need to configure it. You probably missed part of the client instructions, either didn't import the CA, or didn't import it to the right place.

Definitely maybe. Provided thye're not blocking ports. I believe you will want to use "aggressive" and not "main", as it will allow pahse1 IP Address changes.

No, you can't manage them in the user manager. It has to be done in the IPsec PSK tab, or you can install FreeRADIUS and use that for authentication instead.

I've tried a few experiments in strongSwan and could never get more than one to work, but I may just not have hit a winning combination. The problem is having it differentiate the request early enough that it can know to use the other profile. If you want to have two nearly identical profiles except for the authentication, that probably isn't going to be possible

That is not possible with mobile IPsec on pfSense. I'm not sure if it's possible in strongSwan itself. It's very simple with OpenVPN, the RADIUS server can pass back the IP address and even firewall rules in reply attributes.

Last time I tried the walk-through on 2.3.x it worked. What clients? (OS/Client name/etc) What settings do you have set on the Mobile Clients tab and on the tunnel itself?

This system has been upgraded since 2.1.X. Like I said I was able to get it to fail like you are seeing, but simply re-configuring the iOS device made it work with no changes to the server. Something's not right. Not sure where it is. I wouldn't completely reinstall if you haven't blown out the IPsec server and reconfigured it.

@Reiner030: To use also routing from pfSense host to AWS (and not only from LANs) there is additional Outbound NAT rule needed from Any to VPC network with mask onto IPSec interface - otherwise the firewall tries to route over WAN interface directly. Perhaps this can help you too ? (I hope it's okay to dig this post back up) Are you saying to create an outbound NAT rule on the IPsec interface with the source as "any" and the destination as the VPC network? Because I did this and when I try to traceroute from pfSense to a VPC IP it tries sending it out to my WAN (PPPOE) gateway. My setup follows these instructions: https://www.seattleit.net/blog/pfsense-ipsec-vpn-gateway-amazon-vpc-bgp-routing/ - I also tried https://fattylewis.com/amazon-aws-vpc-vpn-with-bgp-an-pfsense/ (my AWS support rep suggested that) and I had the same issue. I also had tried it with static routing but still, no juice.

You don't want to set it to auto in that case, it sounds like it's configured for IKEv1 on the other end, which means any attempts you make on your side with auto will fail. Set it to IKEv1.

Got this mostly fixed. The client side VPN must be created through the Network and Sharing Center (the legacy interface way), not through the Network & Internet - VPN settings page (new, Modern, interface). It works when you do it the 1st way but doesn't work when you do it the 2nd way. If you're connecting to clients on internal subnets through the VPN, you have to update the firewall rules on those clients. The IPSec clients are coming from a new, different subnet and the firewalls running on internal machines need to know that new subnet is trusted. I still don't have it talking to the internet through the VPN, which is frustrating, but it isn't required for my application so won't prevent our 2.3.x upgrade.

https://doc.pfsense.org/index.php/IPsec_Troubleshooting Set the log options as described there and see if you can initiate from the Fortigate side. Even if it doesn't work, the logs will be much more useful in that direction. Odds are you have a P1 or P2 mismatch

@cmb: It hasn't been widely broken in any 2.3x release version. The PFKEY issue in the linked thread isn't common, but is fixed in 2.3.1 (and 2.3.1_1), and had manual fix instructions there since very shortly after 2.3.0 release. @cmb: I'm not aware of any IPsec issues in 2.3.1_1. And here I was thinking it was definitely still in a broken state. I am on 2.3.1_1.. What is the fix for the PKEY issue? Turning up the sysctl values? I have done that but still get the same errors. I shouldn't need to even do that since the fix is in 2.3.1_1, right? [2.3.1-RELEASE][admin@fwslc.alignbi.local]/root: cat /etc/version 2.3.1-RELEASE [2.3.1-RELEASE][admin@fwslc.alignbi.local]/root: sysctl -a | grep net | grep raw net.inet.raw.recvspace: 131072 net.inet.raw.maxdgram: 131072 net.raw.recvspace: 1048576 net.raw.sendspace: 2097152 Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>unable to delete SAD entry with SPI ca856e2c Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>deleting SPI allocation SA failed Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>error sending to PF_KEY socket: No buffer space available Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>unable to add SAD entry with SPI ca856e2c Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>error sending to PF_KEY socket: No buffer space available Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>unable to add SAD entry with SPI d7596024 Jun 21 18:05:34 fwslc charon: 08[IKE] <con1000|109>unable to install inbound and outbound IPsec SA (SAD) in kernel Jun 21 18:05:34 fwslc charon: 08[KNL] <con1000|109>error sending to PF_KEY socket: No buffer space available</con1000|109></con1000|109></con1000|109></con1000|109></con1000|109></con1000|109></con1000|109></con1000|109> My three tunnels remain down. They were up before the upgrade. One of the tunnels connects to AWS and uses BGP. I have turned on the Unity plugin. Not sure what else there is to do.

anybody?

The Feedback forums are for user feedback related to the use and operation of the SMF forum software.  If you need assistance with IPSec, I would suggest the =https://forum.pfsense.org/index.php?board=16.0IPSec forum.