Dump the contents of the generated StrongSwan configuration on pfSense, it looks like you have it configured for esp = aes128gcm128-sha1-modp1024! which is different to the other side.

@jmesser:

I have had no trouble in Ipsec with my 2.2.1 production boxes. 2.2.2 upgrade broke Ipsec for me with 2 P2 entries. when i rolled back to 2.2.1 Ipsec again works without trouble. just FYI.

That's almost certainly fixed by the reqid change here:
https://github.com/pfsense/pfsense/commit/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504f

2.2.1 and earlier have strongswan 5.2.x, where specifying the reqid works around a rekeying problem. 2.2.2 and 2.2.3 snapshots have strongswan 5.3.0, where the problem that required specifying the reqid is gone, and with multiple P2s doing so can cause you to hit a race condition in strongswan where it duplicates reqids, which breaks multi-P2 where you hit it.

The last problem item on the IKE2 setup seems to be DNS.  My network config looks something like this:

LAN: 10.10.42.0/24
VPN: 10.10.69.0/24

We had a dedicated DNS box prior to the pfSense that I'd like to phase out since the pfSense is easier to configure.  From the VPN network I can't get the pfSense DNS resolver to work, but the dedicated DNS box does.

10.10.42.1 = pfSense
10.10.42.6 = DNS server

from my lan i can successfully do the following:
nslookup myserver.mydomain 10.10.42.1
nslookup myserver.mydomain 10.10.42.6

from my VPN I can't nslookup via 10.10.42.1, only the .6 box works.  I've tried telnetting to 10.10.42.1:53 and I'm able to establish a connection, so something about the response is getting lost.

@doktornotor:

the ipsec tab has an "allow all" rule.
See screenshots for all rules.

@shreek:
If i set the virtual address pool in the mobile clients tab to 192.168.23.144/28 and if I manually add the route on the client after connecting the vpn, I get access to the internal lan.
To set the route on Win7 use "route add 192.168.22.0 MASK 255.255.255.0 192.168.23.145" where 192.168.23.145 is the IP of the VPN interface on the client.
The connection was succesfull after following these instructions: https://forum.pfsense.org/index.php?topic=93541.0 and http://serverfault.com/questions/536092/strongswan-ikev2-windows-7-agile-vpn-what-is-causing-error-13801

fw1.png
fw1.png_thumb
fw2.png
fw2.png_thumb
fw3.png
fw3.png_thumb
fw4.png
fw4.png_thumb

Sorry.
I'm using this exact(!) config:

https://doc.pfsense.org/index.php/L2TP/IPsec

Edit:
I did revert to my 2.2.1 snapshot, that one still works, but the "conflicts with IKE traffic" is also there, but the log after is different:

May 12 12:39:23 charon: 05[KNL] can't install route for 79.138.*.*/32|/0[udp/57280] === 83.250.*.*/32|/0[udp/l2f] in, conflicts with IKE traffic May 12 12:39:23 charon: 05[IKE] CHILD_SA con2{2} established with SPIs ce630aa3_i 03d2ee78_o and TS 83.250.*.*/32|/0[udp/l2f] === 79.138.*.*/32|/0[udp/57280] May 12 12:39:23 charon: 05[IKE] CHILD_SA con2{2} established with SPIs ce630aa3_i 03d2ee78_o and TS 83.250.*.*/32|/0[udp/l2f] === 79.138.*.*/32|/0[udp/57280] May 12 12:39:26 charon: 05[KNL] interface l2tp0 activated May 12 12:39:26 charon: 09[KNL] 192.168.42.142 appeared on l2tp0 May 12 12:39:44 charon: 09[IKE] sending DPD request May 12 12:39:44 charon: 09[ENC] generating INFORMATIONAL_V1 request 286907280 [ HASH N(DPD) ] May 12 12:39:44 charon: 09[NET] sending packet: from 83.250.*.*[4500] to 79.138.*.*[55263] (92 bytes) May 12 12:39:45 charon: 09[NET] received packet: from 79.138.*.*[55263] to 83.250.*.*[4500] (92 bytes) May 12 12:39:45 charon: 09[ENC] parsed INFORMATIONAL_V1 request 2737098688 [ HASH N(DPD_ACK) ]

Edit 2:
Ok so I reproduced the error:

Im on 2.2.1 - vpn ok Use built in ugprader to 2.2.2 + Reboot VPN does not work anymore

https://doc.pfsense.org/index.php/2.2.2_New_Features_and_Changes
I see 6 points of IPSec fixes in the patch notes, one is strongSwan upgrade.

Strange I'm the first one with this problem…

I did revert to 2.2.1 for the time beeing.

Ok, I think I've got it somewhat sorted. I had a mismatch on proposals.

May 10 17:57:44  charon: 15[CFG] <7> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
May 10 17:57:44  charon: 15[CFG] <7> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

I was able to switch my DH key group from 4 (2048 bit) to 2 (1024 bit) and now I'm getting a successful connection.

It looks like DNS isn't working right, but I think I can get that sorted. Hopefully this helps someone else!

EDIT: DNS is working just fine (verified via nslookup on OS X client), and I can ping hosts on the network, but I can't access those hosts via a web browser, nor can I access the internet once I'm connected via VPN.

I don't think it's outbound NAT, as I have that set to automatic generation and I can see the VPN subnet in the rules. What else could it be?

It depends on order you create the tunnels.
If you create the tunnel with specific ip first it will be used instead of next one.

@mkaishar:

I can reproduce problem very quickly

P2 lifetime dropped to 300 seconds and when it expires, traffic stops

Oh well back to 2.1.5 because 2.2.x is not production ready from my experiences so far

I have been using 2.2.1 with no problems regarding Ipsec. when i upgraded to 2.2.2 i started having this issue with multiple P2 entries. I fell back to 2.2.1 and I am back up and running with no problems. just thought I would toss that out there.

I "solved" The issue.  I knew the IPsec was working correctly on 2.2.1, so I instead of going 2.1.5 -> 2.2.2 I did a middle step 2.1.5 -> 2.2.1 -> 2.2.2 and all works as expected now

It's an artifact of rekeyed connections in some circumstance we haven't narrowed down yet. It doesn't appear to cause any problems though, and is safe to ignore.

@spetnik:

What would the intermediary devices here be? I tried connecting via my Android phone's tethering as well as a remote simple cable connection. I also tried through a network that is on a SonicWall router that has in the past (earlier pfSense versions) allowed me to connect.

Usually some form of firewall with NAT would be expected if you are not connecting directly.

I would suggest upgrading to IKEv2 and using Windows 7 built in client, Android works well too apparently:

https://raymii.org/s/tutorials/IPSEC_vpn_with_CentOS_7.html

ShrewSoft if you want PSK, but it will not remember passwords by design.

Windows 7 ships with an IKEv2 client that works great with RSA certificates, you can find some screenshots for setting those up here:

https://raymii.org/s/tutorials/IPSEC_vpn_with_CentOS_7.html

Depends how mobile your clients are, OpenVPN/TCP on port 443 has significant advantages for accessibility in restricted networks.

not exactly sure what happened for me, but when i upgraded from 2.2.1 to 2.2.2 half of my ipsec tunnel collapsed. i could still get to the SQL server at our hosting company with SQL management studio, but could not reach the other server there even with pings.  I ended up rolling back to the old version and everything works again. =/.  i apologize, i do not have any logs or screen shots from the failures. there were charon errors though, i do recall that. not being able to find a file or directory or something.  seeing this post made me wonder if it was this issue.

oh. looks like its that same bug a lot of others are having with multiple P2 entries. I have two P2 entries.

I have seen the same symptoms on a pc engines ALIX (not an APU)

The remote end reboots in somewhere between 30 seconds and 1 hour when ipsec (strongswan) is enabled.  I disabled IPSEC and the box is up solid for three hours now.

Details:

Far end PC Engines Alix with 256 MB ram running pfsense 2.2.2 i386 Near end is a generic Atom board running pfsense 2.2.2 64-bit IPSEC phase one is built from IPv4 to IPv4 addresses, both static Phase 2 is a /24 network remotely to a /16 network locally.

I can't see anything useful in the logs after a reboot - they start with Kernel booting.  Even setting syslog to log over the tunnel was not able to produce any logs.

So I'll try this tuneable and see if it does anything, will report in 24 hours.

–-------------

UPDATE - 14 hours later the remote alix has not yet rebooted, but the tunnel is up and stable the whole time.  FIXED for me!  Thanks!

Can you share your config sanitized?

What you can do for now is provide a command to be executed during bootup that clears the states for that specific traffic.

Already there with 2.2.3 snapshots.

You could set the phase 2 configuration in site B to ping an internal IP in site A.

Otherwise it looks like you have a firewall or NAT issue, or accidentally checked "Responder Only".

Thanks for your answers.

Here's how I've solved the problem:
I set up my ipsec connection and "phased around" all my LAN Subnets in Phase 2. To route around, I just needed a couple of phase 2 entries.

0.0.0.0/1
128.0.0.0/2
192.0.0.0/9
192.128.0.0/11
192.160.0.0/13
…

cu
Ben

Interesting, does Cisco follow this policy too?  Here is the reference on the freebsd mailing list.

https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037912.html