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.

@Thale:

Would "Restart Service" work, or does a "full stop/start" refer to an actual stop followed by a start?

Stop it, then start it. A restart in some cases apparently doesn't apply all the config file changes that were made in some circumstance(s) I haven't fully quantified yet.

@doktornotor:

No, absolutely not without posting relevant logs.

This. Post your IPsec logs from both sides. There is no possible way to suggest what to do without having logs of why it's failing.

Can you share the generated config on /var/etc/ipsec/ipsec.conf and the /var/etc/ipsec/racoon.conf from machines?

Yeah that means that something i\might be sending ip ids that are similar.
Usually that is problem on client side since that breaks fragmentation and not only.

It clearly states in 1st post what is the problem.

There's still an open ticket to address that, it got pushed to 2.2.1.

To come back to the problem, if the tunnel is up but no traffic is coming through, can you further specify it?
Is there only some traffic (like small ping packets) that get through or is it nothing at all.
Because I experience a problem where fragmented packets get lost. https://forum.pfsense.org/index.php?topic=87610.0
Maybe you want to perform similar analysis to confirm that your current problem is similar or not.

Just an update:  Today I have the following log entries and SEVERAL entries in the SAD table.

Jan 28 08:24:04 racoon: INFO: unsupported PF_KEY message REGISTER
Jan 28 08:23:29 racoon: [Roseville2Longview]: [206.x.x.x] ERROR: notification 32768 received in informational exchange.

Any thoughts are welcome.  Just a thought; if, on the remote firewall, the key expiration is set to 24 hours AND zero kilobytes, will the key constantly be regenerated?  I have always thought not, but…

In my case all ends are Pfsense 2.2

This was not happening when we had 2.1x