got it via /etc/devd.conf. if WAN-Interface goes down the ipsec restarts.

I have found the fix.

Had to enable "Clear invalid DF bits instead of dropping the packets" in System > Advanced > Firewall/NAT.

The APU Board has 2gig RAM, i also used a board with 4GB, the RAM isn't the issue, the maximum RAM usage was about 20 %. :(

Hi,

Is there any update on showing connected users via IPSEC on the dashboard? 2.2.4
Displays:
Note: There are no configured IPsec Tunnels

although they are working.

Disabled the service, tried to change the handshake for phase 1 to certificate, but couldn't get it to work. Changed it back to psk, changed encryption type to blowfish and DH to 5 from 2 (honestly, just because I was bored). Started the service back up, and it reconnected… holy crap, I hope I never have to come back to this forum again! Down with PFSENSE!

Means the remote end is trying to initiate a connection (hence the "responder" part), with settings that don't match what you have configured.

If you're on 2.2.3 or newer, multiple P2 is fine.

Seems like 2.2.4 got even worse performance. The results is fluctuating and I'am not sure if AES-NI is even being used. Anyone got a working IPSEC setup using AES-NI?

[root@test3 strongswan]# iperf -n 32M -c 10.75.0.1 -P 5
–----------------------------------------------------------
Client connecting to 10.75.0.1, TCP port 5001
TCP window size:  204 KByte (default)

[  7] local 10.75.0.3 port 42604 connected with 10.75.0.1 port 5001
[  3] local 10.75.0.3 port 42600 connected with 10.75.0.1 port 5001
[  4] local 10.75.0.3 port 42601 connected with 10.75.0.1 port 5001
[  5] local 10.75.0.3 port 42602 connected with 10.75.0.1 port 5001
[  6] local 10.75.0.3 port 42603 connected with 10.75.0.1 port 5001
[ ID] Interval      Transfer    Bandwidth
[  6]  0.0- 8.0 sec  32.0 MBytes  33.5 Mbits/sec
[  7]  0.0-17.2 sec  32.0 MBytes  15.6 Mbits/sec
[  5]  0.0-20.0 sec  32.0 MBytes  13.4 Mbits/sec
[  3]  0.0-25.6 sec  32.0 MBytes  10.5 Mbits/sec
[  4]  0.0-26.5 sec  32.0 MBytes  10.1 Mbits/sec
[SUM]  0.0-26.5 sec  160 MBytes  50.7 Mbits/sec

Note: Have now discovered that "top" shows some load.. Idle interupt goes to zero and "nice" goes up:

Thanks for that hint, I already did that and managed to get DHCP relay into the tunnel (without that workaround it refused to send the paket into the tunnel and showed up something like 'no route to host' in DHCP-logs). With the route from the workaround you suggested I managed to get the request out to the DHCP server, but it refuses to re-enter the pfSense it originated from.
As a workaround for this I took another pfSense behind the pfSense (which was intended to to the relay in the first place) as LAN-B-client-only doing the relay instead of pfSense2. This worked without any problems. It's just the need of a third machine doing the relay since it refuses to work on the same one that is the end of an IPsec tunnel.

@cmb:

[…]it's probably not a great idea to rely on a remote site over VPN for your DHCP, unless in a scenario where that entire network is dead anyway if the remote site is unavailable.

I totally agree; that's what I'm thinking too, however I'm being told to get this working exactly this way, no matter what problems it brings.

Thanks for your help ^.^

Those aren't actually errors. Newer racoon versions log those more correctly as informational.

Dynamic gateway probably means you have a P1 mismatch, though you're on such an outdated version it's hard to say for sure there.

They each have a distinct purpose.

Per-user PSKs are for Mobile IPsec that is PSK only (though these may also be entered on the IPsec PSK tab, they are on users for convenience)
IPsec with Xauth PSK is the "Group Key" in clients
PSK tab in IPsec is for entries that are not per-user, such as EAP entries, allusers entries for L2TP/IPsec, and so on.

I don't mind taking the time to debug.  But so much stuff is spewed into the log that I have been unable to find any thing that hints at the problem.  Chris has had access to my system since 2.2 and I don't think he has had any more luck identifying the problem.  I have 17 VPN connections but they are all for my use, and I have backup OpenVPN connections as well so I can "afford" to keep looking for a solution, but it is a pain to reboot PFSense every couple of days (and it reeks havoc with my Zabbix monitoring).  The 17 end points have various IPSEC connections between them, but I have left them all running 2.1.3 until IPSEC is working reliably (or I give up and convert all the tunnels to OpenVPN)

i have same problem and ipsec tunnel established nut traffic from two site not pass and packet droped like this

Bytes-In: 0
Packets-In: 0 : 550
Bytes-Out: 0
Packets-Out: 0 : 0

how can i fix this enybody have this problem  :'( :'( :'( :'( :'(

sorry…not the compress algo...its the pfs setting only

For others following this thread, the (new) issue of split-tunnel/routing with IKEv2 was moved to this thread: https://forum.pfsense.org/index.php?topic=97627.0

Yes, I already tried that, SAs come up green, but cant move traffic.

I have Main office, and new satellite office B,

For a long time at the main office, I have had 2 ipsec VPNs to 2 vendor networks: Site1, Site2, I wish OfficeB could access devices on these vendor networks, but it can only ping the main office, the main office has no trouble pinging everyone…. some sort of routing problem?

This is the main office side:

Then the satellite office:

I should be able to ping 10.1.x.51 from officeB, but it only works at the main.

I am also using manual out NAT, do I need to create rules for the ipsec interfaces? Which interface would the rule apply to?

Packet capture on the IPsec interface, is it getting there? If so, switch to LAN, it getting there?

@ocz:

Can you really confirm, that your described behaviour is solved by upgrading 2.2.2 -> 2.2.4 ?

Where the root problem is the same, yes, upgrading will fix it. For any IPsec issues on 2.2.x versions along the lines of what you're seeing, first upgrade to 2.2.4.

Since you're already there and seeing the same, that's likely a circumstance where the configuration was wrong to begin with, but happened to work. Primarily the situation described here:
https://doc.pfsense.org/index.php/Upgrade_Guide#Stricter_Phase_1_Identifier_Validation

You're best off starting a new thread describing what you're doing, what logs you're getting, etc. There are countless possible reasons you can get decryption failed logs, and the circumstance OP described is definitely fine in 2.2.4.