Hi Upgraded to Update-2.2.4-DEVELOPMENT-i386-20150704-0731 IPsec works with this version, no configuration changes where required. Did not get time to test the MSS clamping, needed the network so the choice was go back to 2.1.5 or try 2.2.4 Development System is 32 bit TSO and LRO where not disabled The good news is that the problem in 2.2.3 seems to have been resolved in 2.2.4 Development Thanks markl

@jly2680: ipsec/ikev2mschapv2 bec l2tp has some l2 overheads and outdated. whut?  :o

just for a positive update : it started working by itself wothout any intervention. i've lost a part of the log (maybe log rotate process …) but look like ipsec reset on 4th july and then the faulty vlan work now over ipsec very very weir but solved now  :D

Did you read this first? SNMP-OIDs for monitoring pfsense OIDs for pfSense on Alix pfSense MIBS 1 pfSense MIBS 2

Please try out to use the "aggressive mode" on both sites!

Guessing your wireless is on a different subnet? You need a matching P2 for that network.

This was fixed in 2.2.4 last week.

After disabling and enabling the phase 2 on one end, the tunnel came up. It was not possible to ping through the tunnel but it looks like the routing works. I then checked the ipsec firewall roules but they were ok (IPv4 * * * * * * none). I also added such rules on the lan interface on both ends. Still, the ip is not pingable. EDIT: After adding an outbound NAT rule and switching to hybrid mode, I can finally reach through the tunnel. Adding a third phase 2 shows the red arrow again on this phase 2. Re-enabling it does not help, even after a few times. The ipsec log shows the phase 2 as if it was connected: charon: 10[CFG] received stroke: add connection 'con1002' Jul 7 22:29:48 charon: 10[CFG] added child to existing configuration 'con1000' Jul 7 22:29:48 charon: 07[CFG] received stroke: route 'con1002' Jul 7 22:29:48 ipsec_starter[35735]: 'con1002' routed But the red arrow on the status page stays and the tunnel is not connected in fact.

Still waiting for help; yes, it works fine under IKEv1; but need to have it working in IKEv2.  ;) Either with hack, or NATting 4 (was 2 before) local subnets 10.1.10.10/24,10.1.10.20/24,10.1.10.110.110/24, and 10.1.10.120 into 10.41.38.0/22, so we can only use 1 SA. Tried NAT 1:1 but that did not work. Any help appreciated.

@cmb: I'm going through all the possible combinations there now doing testing, with an automated test setup to iterate through all the possibilities. We'll have that resolved for 2.2.4. Awesome!  :D

Can you post debugging logs of both sides?

i have tried specifing the wan ip address as CN in the certificate …. no luck. can anyone share their experience on ipsec with rsa please?

Double check your configuration. IKEv1, main mode? If you had something that worked, it came up, then you changed something so it no longer matches (like switching to IKEv2 for instance for that log), the already-negotiated connection would stay up for the lifetime. Then come time to rekey, it fails as the config is no longer valid.