This issue has not reappeared in the last few days, and it used to occur at least once a day. The only major change to my configurations is to improve the stability of the PPPoE link to the Internet. I was using a USB Ethernet adapter for my PPPoE link and the link was quite unstable, typical PPPoE uptimes were a few hours max. I have since changed to a VLAN based solution to get my PPPoE traffic out of the pfsense environment. The result of this is that the PPPoE is now significantly more stable and at the same time the IPsec phase1 without phase 2 problem appears to have gone away. As well as being more stable the time to reconnect when the PPPoE link does fail has increased. With the USB Ethernet adapter the PPPoE Daemon would receive a TERM signal, shutdown, and then immediately reconnect. Now all the PPPoE outages look more like ISP issues and are loss of LCP echo, followed by a few attempts to reconnect. So the PPPoE link is down for a much longer time and does not instantly reconnect. So at this stage it looks like the IPsec loss of phase 2 may relate to the manner/frequency of link failure on the Internet link. I have left the IPsec links in IKEv1 and if the issue occurs again then I will hopefully be able to supply the appropriate logging information. Tim

How many phase 2 entries do you have? Make sure you're not running into https://forum.pfsense.org/index.php?topic=106260.msg592087#msg592087. Cheerio, Harry.

another error have been able to login with shrew vpn client soft but now no more access. error showing when login is negotiation timout occurred i have uninstall and reinstall still the same error. kindly help.

I had the same problem when upgrading from 2.1.5 to 2.2.6(chnging hardware and restoring the config etc.), in the end i needed to re-specify what interface the local endpoint of the phase1 entry, seems to have reset itself to the interface and not the virtual IP that was originally used. Hope this helps someone else.

Read the warning note at the top of the wiki doc you linked – that won't work for Windows, for the exact case you have encountered.

The only way I got it to work was to: Set up one pfSense gateway to connect to the internet via pppoe set up another pfSense as an IPSEC initiator and set up the IPSEC connection. Box (1) is my default gateway to the internet I route all traffic from (2) to (1) so that IPSEC box can route outwards to establish the IPSEC connection I set up a customer route from (1) to (2) for any traffic going to the remote site. PM me if you want more details.

That's the nature of how it works. Traffic matching the SPD is intercepted and sent across the IPsec if there is a matching SA. If the IPsec can't come up, it gets dropped. IPsec transport mode with a gif or GRE tunnel and a dynamic routing protocol is how failover is accomplished. Or policy routing though that's usually more complicated since you have to make sure routing on both ends is updated appropriately.

Yes, this page is a valuable resource also for other scenarios. It was the first reliable source I came across stating that the built in client from OS X should be working in this setup at all.

Thanks makes total sense. thanks for your help

No, they are not encrypted on disk. They're in the clear because they have to be for EAP to work properly with strongSwan (I misspoke and said mpd earlier, not sure where that came from…) https://doc.pfsense.org/index.php/Why_are_some_passwords_stored_in_plaintext_in_config.xml

You have to add a P2 with the NAT in that case, otherwise it never enters enc0 to be translated and sent across.

I have the same problem. Can you share which NAT settings did you changed? Thanks

Had similiar problem (0.0.0.0 route always added) when creating VPN from Windows GUI and PowerShell helped. Thanks.