It's been running stable for me since I made those changes referenced previously in this thread.

suggest we remove this from IPsec.
I'll repost in hardware - turns out my entire inbound traffic stream is limited to 1.2mbs and it has nothing to do with the VPN.

@jimp:

Looks like this issue: https://redmine.pfsense.org/issues/7929

Having the same component with multiple values is tripping up that section of code, apparently.

I don't have time to look into that one today, but it doesn't look too hard to solve, I can check it out next week though.

The workaround from the bug above did it. Now it works, thank you very much. Hope this bug gets patched on next release.

Best regards.

I hit something similar today. I dont have an answer, but it got me wondering if the config.xml has a defined schema ? Maybe there are additional parameters that can be manually defined in the xml ?
I have been unable to find a schema so far.

Yes you are correct. Stood up a test server and 0.0.0.0 works. If you inspect the ipsec.config file used by Strongswan the right value is 0.0.0.0 so pfSense does not parse it in any way. Yet there is no mention of 0.0.0.0 in the Strongswan docs (from what I could find)
In my situation I also needed to be able to have multiple tunnels configured, all allowing the incoming connection from any source IP. However I discovered that multiple tunnels cant all have 0.0.0.0 or % any. First the Web Gui will complain that 0.0.0.0 is in use in another Phase 1 config, and the Web Gui wont allow %any.
But even if I add the 0.0.0.0 or %any directly into the config.xml via the Diagnostics->Edit File method I get not luck. I see that the values actually make it all the way to the ipsec.config file after the VPN service is rebooted, but not all Tunnels will connect. Strongswan's lookup process during the Phase 1 incoming connection will match on the first Tunnel config in the list, then a Phase 2 will initiate but fail if the incoming connection is not actually for that first tunnel config.
I was hoping that the lookup process uses more than the peer and local IP addresses, but I don't think it does.
In my situation I've had to fall back to DDNS to make all this work.

Just for additional info, Android 8 appears to proffer the following:

IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

Again, this leaves only 3DES/SHA1/MODP1024 as the common cypher which is less than ideal.

You are not showing the phase2 config you are using in the pfSense and that is what it is failing.

@barnettd:

Totally agree. We have been moving our small remote sites from ASA 5505s to the SG-2440s, but the ipsec issue has been a major pain point and I'm starting to regret our move…
The ASAs are more expensive and are more limited, but ipsec failover worked really well.

Yeah… I installed one at my house, one at my company's office and one for a client just a few weeks ago. That will be the last one and this great pfSense adventure is gonna be over.

I chose to support it, but I regretted it. I'm probably gonna switch everything over to MikroTik and Ubiquiti. The first one provides real support without spending in the thousands and the second one always seems to just work (& is incredibly cheap).

Good luck!

Another update:
    Reinstalled the firewall from scratch, and everything works fine.
    For about 10 minutes. Then I observe the symptoms from https://forum.pfsense.org/index.php?topic=117827.15
    I see the state table for the IPSEC interface full of nonsensical entries as well.
    This seems to affect ONLY TCP replies to a ipsec mobile client. ICMP and UDP are unaffected, as is downlink TCP.
    Testing with iperf, I observe 200mb/s down, and one packet up.

Edit:
  I've resolved this.

My current configuration is using RADIUS and MSCHAPv2 credentials, so multiple devices for the same user, with identical credentials.
  These were getting mapped to the same SA, apparently causing forwarding wierdness?

The fix was to set peer identifier to peer ip, and replace sa to never.
  Finally, to get windows 10 working, I needed to disable hardware checksum offloading. This is with a chelsio t520-so-cr, wan on a vlan, on a lacp lagg. So I may be poking an edge case. It reported bad udp checksums on the fragments, and pfsense didn't even see them when not in promiscuous mode.

Is there a wiki or something where I can contribute troubleshooting steps and known working settings? The failure modes were not what I expected, which made this take much longer to troubleshoot.
I expected that either only one client would work, or they all would, not all working for download, but breaking state tracking.

Unfortunately, the functions that you need in powershell aren't available under windows 7 like they are in windows 10.  I've downloaded literally every version of powershell.  If you were to find a way, I'd be very interested in seeing how this is done.

For now, I'm rolling with 3des which I cringe at the idea of.  The only Windows 7 PC that is holding me back is my work laptop.  Luckily, I'm due for an upgrade so I've asked our IT group to issue me a new PC with windows 10 so I'm pretty excited to get some new hardware which I'm confident will allow access to the functions needed to configure the specifics.

Much appreciated for the guide and I'll be watching if you post anything on the Windows 7 front!

yea, did you follow the guide?  ive made a few screenshots of all i i changed.


I have a good new, the VPN connection is actually connect.
For feedback, my problem was that my peer router are in the same situation that me (another router is on front internet and the VPN router are next that).
So, when I configure my VPN I have indicate the Public IP for identify the remote router but, with the private IP the VPN work correctly. [The remote router don't modify his identify IP].

Thank for your assist.