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…

SOLVED! After looking again I finally realised my phase 2 was 10.95.0.0/16 on one side and 10.95.00/23 on the other. That doesn't include 10.95.95.103…. So it is going to WAN instead. I'll have a second look on tcp/ip for dummies :( Sorry for the waste of time. What surprises me highly though is that a phase2 is established, even though there is a subnet mismatch. The SPD established is 10.95.00/23, likely because that fits in 10.95.0.0/16. I always understood that in case of a mismatch it would fail at all. In that case the cause was much more clear.

oh damn this was the reason: Proxmox: IMPORTANT: Enter the web GUI and go in System > Advanced > Networking and flag Disable hardware checksum offload. If you don't do it layer3 traffic from lan to wan will not work, or will be really slow (but traffic to/from the firewall will work fine: see the pf sense wiki about virtio for details https://doc.pfsense.org/index.php/VirtIO_Driver_Support )

By looking further, IPsec is generally not working well with NAT-T. I have many traffic drops. neither with multiple Phase2, Even if status shows tunnels online. Rebooting make tunnels work again for some time. I have changed NAT-T Tunnels with OpenVPN as i'm 100% pfsense on remote sites. Since it works much better. I have just trouble when rebooting server. I'll make a topic. Regards

The backup node will not try to connect any tunnels until it switches to master.

Yeah that is one second of logs that shows charon not taking action because it is waiting for another action to complete, which is perfectly normal. Going to need more logs than that. Set IKE SA, IKE Child SA, and Configuration backend logging to Diag and post them up. Sounds like an ISP might have done something.

@mikee: Hi. You are requesting to configure a dynamic endpoint. You should be able to achieve this by using 0.0.0.0 as the IP of the remote endpoint. This should allow ANY remote IP to connect. Anyway with this value the tunnel will only be able to be started from the remote side because we (the local side) do not know where to talk to. The VPN will be down until traffic from the remote side fires the VPN up. Cheers. How could I miss that, thank you very much!

Thank you, much appreciated. I'll continue to plug along.  My mobile phone has stopped connecting now for some reason, nothing in any settings has changed, just not connecting.  Rebooted PFsense, but no joy. When I have time, i'll look further into it. Thank you Willo

The logs are showing an authentication failure.

When you use certificates to validate a VPN the remote side must have a way to validate the received certificate so you must have the public key of the sender CA installed on it. Have you installed the certificate of the CA in the remote side?.

To be able for the community to know if you missed something perhaps you could first post what your actual config is…. For what you say it looks like you have a hub mode config: ALL traffic is sent to the VPN when connected. But again, post your config or we all are blind.