I ended up manually editing /cf/conf/config.xml to achieve what I want, just copied the relative code and changed the ikeid in phase 1 and 2 and uniqid in phase 2 , after that I was able to use the  pfsense GUI again. I now can connect from android, windows, and apple devices using different authentication methods.

https://forum.pfsense.org/index.php?topic=138987.msg761370#msg761370

@dobler: I figured it out. In my case it was a vpn configuration issue. Make sure in phase 2 that you use 0.0.0.0/0 for local network if you want to access traffic outside. Just want to say I found this thread on Google and after searching for like 2 hours this is what fixed my problem.

@NogBadTheBad: Just had a play you can bind iperf to an ip address via the console using -B [2.4.1-RELEASE][admin@pfSense-vm1.localdomain]/root: iperf -B 10.0.1.1 -c 10.0.2.1 –---------------------------------------------------------- Client connecting to 10.0.2.1, TCP port 5001 Binding to local address 10.0.1.1 TCP window size: 64.2 KByte (default) [  3] local 10.0.1.1 port 2344 connected with 10.0.2.1 port 5001 [ ID] Interval      Transfer    Bandwidth [  3]  0.0-10.0 sec  152 MBytes  127 Mbits/sec [2.4.1-RELEASE][admin@pfSense-vm1.localdomain]/root: [2.4.1-RELEASE][admin@pfSense-vm2.localdomain]/root: iperf -B 10.0.2.1 -s –---------------------------------------------------------- Server listening on TCP port 5001 Binding to local address 10.0.2.1 TCP window size: 63.7 KByte (default) [  4] local 10.0.2.1 port 5001 connected with 10.0.1.1 port 2344 [ ID] Interval      Transfer    Bandwidth [  4]  0.0-10.0 sec  152 MBytes  127 Mbits/sec I get "Can't assign requested address" if I try that.

Really this is not a IPsec VPN problem, VPN Itself working good because I see ICMP packets travels from one interface side to other interface side at the end of tunnel. Yesterdat I'll figured it out because when I added NAT portfowarding rule on IPsec  and virtual IP om MODEM interface for ICMP, then after commit I glad to see ping travel back on my admin pc station. ICMP packets roadmap like below: from 192.168.2.236 ping to 192.168.0.1 > echo request routed at  192.168.2.1 (pfSense gateway) under VPN tunnel. from remote pfSense router  VPN enpoint  the echo request route to 192.168.0.1 but for a kind of  behavior  I dont'know the port fowarding nat rule translate ICMP ECHO request from 192.168.2.236 to 192.168.0.99 at the MODEM interface. Packets ICMP ECHO request now will end to 192.168.0.1. and it will reply correctly sending ICMP ECHO reply back to 192.168.0.99. So at this point pfSense router I guess made auto rule for NAT  back the ICMP ECHO reply  to my admin station 192.168.2.236 previously triggered by NAT portfowarding. This works only with ICMP traffic type, TCP traffic not work ame as I described. I just decided to write new thread under NAT forum section for sekking to figure out enough about NAT LAN TO LAN translation for IP address, I guess to do with 1:! NAT But I'm not fully understand how it works at this time. https://forum.pfsense.org/index.php?topic=139240.0 A side note, I unable to dump, (packet capture) the ICMP traffic under MODEM interace + NAT portfowarding rule. simply  all left blank!! this is very strange for my opinion.

@barnettd: I thought it might be a cache or browser issue, but its the same in IE, Chrome, and Firefox. Anyone else experiencing this? Confirmed. -> https://forum.pfsense.org/index.php?topic=139163.0

It is quite a complex thing to do if you are not used to IT.  Have you followed the L2TP instructions in the PFSense Book?  If you buy that or can get it for free with your hardware, then try that first.  The full instructions are in it, apart from a single crucial step which is undocumented, and that is to allow your network to accept PING.  https://forum.pfsense.org/index.php?topic=1933.0

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.