It's a bug in the windows client that strongSwan won't work around. See https://wiki.strongswan.org/issues/220 for part of it, search around for more context.

If you want it fixed, advocate to the strongSwan project that it should be fixed.

Though everyone has moved on to IKEv2, which is much better all-around, so few people are still interested in working on L2TP/IPsec.

was wondering if you have had any update on this?

You have a mismatch of some sort on the phase 2. Maybe the PFS key group, but check it all.

The initial connection comes up fine. Just after the 24h disconnect the tunnel will not be reestablished and I get the same log entries.

It seems the ISP cut the line all 24h once, like here in Germany and the IPSec connection is not coming
up proper again.

Confusing but maybe helpful: If I use another IPSec connection from my Smartphone (with VPNCilla, inside LAN) to the Fritz!Box then the pfsense tunnel comes up simultaneously  :o

If there will be then a packet flow through the tunnel it will be perhaps revive the older IPSec VPN tunnel
also again and its up then. Did you try out to get from your PC a link or data flow through the tunnel
by opening the briwser and start connecting some devices on the other side of the VOPN tunnel, or perhaps
another program running on a device in the LAN?

@jimp:

How many Phase 2 entries do you have?

IIRC AWS will only allow so many P2 entries (3, I think) and if you establish another one after that, they will disconnect one of the previous entries in exactly that fashion.

Hi,

I had since found the issue and that was in fact the problem. These symptoms are buried in this Amazon tech note https://aws.amazon.com/premiumsupport/knowledge-center/vpn-connection-instability/. Really difficult to track down because you don't have access to any logs on the AWS side…

Cheerio, Harry.

Basic network config on the hosts in question the next most likely. Missing or wrong default gateway, wrong subnet mask.

You're at least a version or two behind. Upgrade, then if you're still having an issue, post your IPsec logs again and what you're trying to configure.

@Garrett:

Just found a workaround by appending another bogus domain name in my split-dns list from: "mydomain.com" to "mydomain.com bogus.com". That seemed to do the trick.

That'll work around it. The root issue, which was a client-side problem, was fixed in OS X El Capitan for sure, and I believe a newer iOS version than this thread originally referenced as well.

For local clients and EAP-MSCHAPv2, they go on the PSK tab, with entries set for EAP, as described in the documentation:

https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2#Create_Client_Pre-Shared_Keys

Hi,

Alternative you Need two ip addresses at colocation, setup transport IPSec connections and gre Tunnels over it.

Sorry for spellings Tablet with wrong keyboard

Best regards
Thomas

Config can differ as initiator vs. responder. UDP 500 traffic could be blocked in that direction but not the opposite. Regardless you need to look at the Juniper side and see why it's not replying.

The Juniper is first not replying, and second, sending a delete. No way to tell anything useful from that side's logs in that case, check the logs on the Juniper side.

I am trying to do the same but confused as to your explanation.  Any screenshots would be great!

2.3 is not affected :)

Seems like pfSense auto adds a NAT rule (default "Automatic outbound" is selected in Outbound "Firewall: NAT: Outbound").

I changed Outbound to "Hybrid outbound", and added an exception "Do not NAT" with the subnet used for L2TP; see attachment. Image is manipulated to mask my real IP/mask, instead using 8.8.8.0/29 as the example in my previous post.

outbound.png_thumb
outbound.png