Update #2 This issue is still unresolved. However, I was able to properly configure the Zyxel to auto connect (its incoming VPN) whenever it determines that a connection is required. I would still appreciate if any suggestions can offered on why the pfsense can't connect to the zyxel but the zyxel can connect to the pfsense.

Have you enable traffic to flow in the firewall rules? There is a separate FW rules section for IPSec channels.

:-[ just realised I'm doing this on a test pfSense, not my live one so the IP address I was trying to ping was wrong. Once the VPN is active I can ping the test pfSense box and a client in that IP Range. Connect seems stable for the last few minutes. Couple of queries… Should I be able to ping the VPN user from the LAN or pfSense box ? I can't. When the VPN is connected the VPN user doesn't have internet access. If I remove the 'use default gateway on remote computer' then they do get Internet access but nothing across the VPN. Is it possible to have VPN traffic go across the VPN, but other traffic go out via the VPN users own Internet ? Thanks

Thanks jimp. This answer helped me resolve our issues with Mac's not being able to connect (and also Windows clients needing to disable the EKU check). When I created the Server Certificate initially I had used one address in the Common Name and a different one in the Subject Alternate Name. I created a new key with the Common Name and SAN matching (in System > Cert. Manager > Certificates) and then changed the certificate being used in the Mobile IPSec Phase 1 entry (VPN > IPSec > Tunnels > - Edit the Mobile IPSec Phase 1 entry - My Certificate). Everything now works perfectly for both Mac and Windows (without the registry setting change). Much appreciated. Perhaps it's worthwhile providing some more info in the documentation about why the IKE auth error occurs as well as providing the EKU Check registry hack to get around it. Thanks again, we can now move from PPTP over to a secure VPN technology. :)

I maybe facing these same errors. Does the connection work if you attempt to connect from the Cisco firewall?

An unmodified Windows up until 10 can use the following for Phase 2 (ESP): ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ As you can see there is no option for SHA256 at this place to choose. It is questionable if this is a real problem because SHA1 is used for integrity in this context, so the upmost would be to send invalid (random) data which claim to be valid. The encryption (confidentialy) should not be broken because of this. You might also try the NegotiateDH2048_AES256 registry key to get more modern ciphers to choose from. Regards Andreas

did we have any other idea?

For those who still have problem with Shrew VPN client and pfSense Mobile Client:  to make it work try the following settings in the Shrew client: a) General -> Auto Configuration -> ike config pull b) Phase 2 ( this is what  gives you the grief or at least what is being discussed in this topic) -> esp-aes / 256 / md5 / pfs - group 2 (can be any if set properly on both ends) and everything should work. If it does not, run Shrew VPN Trace ( a utility coming with the Shrew VPN) , change the debug log verbosity, you will get a log. Examine both logs (Shrew's one and pfSense's IPsec log and things should be more or less clear, you will see what is wrong). That's beyond me  why when I set up a site to site tunnel in Shrew  I can easily do that with manual configuration  and phase 2 settings mentioned in multiple pfSense tutorials: eso-aes / 256 / sha 1  But for  the mobile client pfSense requires  esp-aes / 256 / md5 - that is utterly strange. Over last 2 days I read a lot of posts on this forum and other places regarding Shrew VPN related problems. I guess it speaks  a volume. Anyway, I am glad that eventually I made it work.

To answer (some of) my own questions: I chose a reboot https://forum.pfsense.org/index.php?topic=124304.0

The second P2 (may have) needed a reboot to come up. It is now working successfully on the independent OPT1 subnet via IPsec. I tried a restart of the IPsec service, at both ends - that didn't help. A reboot, which presumably shouldn't have been necessary(?), did the trick. Hope this helps…