Hi, I can confirm I had the same symptoms with 2.2. But I had to go back with 2.1.5 because of IPsec multiple p2 problems. So you are not alone. Regards

If you apply this patch then /usr/local/sbin/pfSsh.php playback restartipsec should work.

Attached another set of logs after a disconnect. This time with compression ON I can also see this on the console: ipcomp_output_cb: compressions was useless 104 - 20 <= 86 1.1.1.1.txt 2.2.2.2.txt

new topic for same problem ? :o yes main mode on both. I redo a config vpn to test.

You don't actually have to use the public IP it's using, for that case behind NAT you could let it use its private WAN IP as the ID. Just make sure both ends are set to match accordingly for that private IP.

Thank you very much ermal, it seems the farp plugin would enable both scenarios I'm considering and it would explain why phase 2 entries for the virtual network assigned to mobile clients do not work as I was expecting.

@cmb: @doktornotor: What kind of holdover? 2.1.5 was using racoon, not strongswan. Yeah, the 2.1.5 config was for racoon, strongswan in 2.2 certainly isn't picking that up. The strongswan.conf file doktornotor pointed out is the only one it can load the banner from. It definitely couldn't persist across a reboot if it's correct in strongswan.conf. Maybe the client is caching it? Or you're connecting to a different server. We're definitely connecting to the correct server, but I'm wondering if the client is caching it. We'll completely remove the connection on the client and rebuild it. Thanks.

Hi, thanks for the replys… I'll be doing this changes this afternoon, and I'll leave a feedback. Thanks for the help

@cmb: Go back to IKEv2 on both sides. Then stop and start strongswan on both sides to make sure it definitely clears out the old IKEv1. That should do it. If you still can't pass traffic, post back what your IPsec status screen looks like. If it doesn't work, PM me if we can arrange remote access or Gotomeeting to check it out. Thanks for your reply, I have finally managed to make it work but unfortunately i have still had to revert back to 2.1.5, basically for IPSEC between 2.2, i had to create the tunnels all over again and disable cisco unity puglin, Also the tunnels only manged to start up for me in IKE V1, the reason i reverted back to 2.1.5 is because after disabling Cisco unity plugin, all my tunnels to our HO's Hub wouldn't start up. (they still use Cisco units) unfortunately i didn't have enough time to fiddle with this more as i already had appx 8 hours downtime and cannot push this anymore. thanks for your help again. i will definitely update to 2.2 once these outstanding issues have been address.

OK, removed manual routes I added, disabled IPSec, rebooted, re-enabled IPSec - routes are there: /root: pfctl -sa | egrep "isakmp|nat-t|esp" | grep pass pass out proto udp from any to any port = isakmp keep state label "IPsec:  any  - outbound isakmp" pass in on vr1 proto udp from any to any port = isakmp keep state label "IPsec:  any  - inbound isakmp" pass out proto udp from any to any port = sae-urn keep state label "IPsec:  any  - outbound nat-t" pass in on vr1 proto udp from any to any port = sae-urn keep state label "IPsec:  any  - inbound nat-t" pass out proto esp all keep state label "IPsec:  any  - outbound esp proto" pass in on vr1 proto esp all keep state label "IPsec:  any  - inbound esp proto" Thanks!

The option to control the behaviour as a responder only will be on 2.2.1

@Derelict: @NinjaActionJeans: Doesn't look like I can add another phase 2 to the remote device. Primary reason I'm replacing Cisco RV042s with pfSense.  That and a lack of OpenVPN.  Good luck. 10.0.0.0/8 worked thx!!

For radius settings you need to restart ipsec service after configuration.

From the looks of that, whatever is doing the NAT is dropping fragmented traffic. Where you see it leaving one end, and not showing up at the other end, something in between is stopping it from passing.

@Clouseau: 10:52:02.472533 00:10:be:0c:85:47 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.139 tell 10.0.0.113, length 46 10:52:03.471592 00:10:be:0c:85:47 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.139 tell 10.0.0.113, length 46 There you go, your subnet mask is wrong on 10.0.0.113. It should never ARP a remote device.