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.

So after changing Phase 2 lifetime to 86400, the connection is staying up, after the one hour mark passed. So the question is now, I believe, how can I ensure that Phase 2 key renegotiating succeeds every hour?

I just setup a 3rd side and I can't access my warehouse side with any application that some of my equipment need. Like POWER ALERT software for TRIPP LITE PDUs. when I use firefox to access any of my PDUs there is no problem, but when I use POWER ALERT to manage any of my pdus or remote desktop to access any of my warehouse windows servers I also can't make a connection I disabled the windows 10 firewall and my bitdefender firewall and windows server firewall to see if it is the firewall problem but it wasn't. this time I have state from 3rd location to the warehouse side and back. I attached the rules of my both sides I have to fix that because my work depend on it Thank you [image: ipsec-bs.jpg] [image: ipsec-bs.jpg_thumb] [image: ipsec-eg.jpg] [image: ipsec-eg.jpg_thumb] [image: ipsec-rules-bs.jpg] [image: ipsec-rules-bs.jpg_thumb] [image: ipsec-rules-eg.jpg] [image: ipsec-rules-eg.jpg_thumb] [image: ipsec-wan-rule-bs.jpg] [image: ipsec-wan-rule-bs.jpg_thumb] [image: ipsec-wan-rule-eg.jpg] [image: ipsec-wan-rule-eg.jpg_thumb] [image: lan-rules-bs.jpg] [image: lan-rules-bs.jpg_thumb] [image: lan-rules-eg.jpg] [image: lan-rules-eg.jpg_thumb]

Hi i use openvpn gui. Please write me exactly the commands and in which router to enter them or through scratch images show me in which menu exactly how to introduce you I beseech you

Better question for a windows forum or your windows domain admin.

Thanks Derelict - I've switched over to DH14 and managed to spin up a MacOS Sierra install on VMware Workstation to create the proper VPN profile.  All working now after modifying the registry on Windows 10 and using StrongSWAN on Android. Much appreciated.

I did figure it out. I have created a "LANGATWAY" that is my pfsense LAN interface IP adress (192.170.0.1) then i have created a static route Azure virtual network via "LANGATEWAY" Gateway Name Interface Gateway Monitor IP Description Actions LANGATEWAY LANIPV4 192.170.0.1 192.170.0.1 Lan gateway Static Routes 192.168.48.0/20 LANGATEWAY - 192.170.0.1 LANIPV4 Hope this will help others that will face same issue.