Release of v17 MR-2?

Exact same problem here. We have 20 SA's though. When it drops I usually have to reconnect it multiple times because only a few SA's will come up together.

My VPN is to Azure and, knock on wood, it's been stable for a couple weeks steady now with only an occasional tunnel pop (seems like a rekey and it never completely breaks traffic). Given the other reports that HA tunnels don't work at all, I'm hesitant to even touch it. As I may have mentioned I had to create a custom IPSEC policy in Azure to align with the config on the XG and even then had to fiddle before it worked reliably. I'm confident Sophos will get their act together on this, otherwise I would have scrapped the XG's and thrown in something else by now.

Ryan,

Out of curiosity, do you have overlapping networks between local and remote side of the ipsec connection by chance?  For for example:

Lets say at the branch office where the sophos is  I've got a 192.168.100.X/24  as the local LAN subnet that's behind the XG. Then on the remote side of the ipsec(cisco at HQ)  we've got a 192.168.0.0/16 setup on the cisco.   I was just wondering if there's an issue with those overlapping subnets on either end of the connection.  I've seen some posts on some of the Strongswan boards about this, but nothing that mentions that the SA's drop off, more of routing issues than anything else.

Thanks,

-Scott

The problem is many of use were waiting eagerly for v17 BECAUSE they brought in Strongswan with IKEv2 - a requirement for route-based tunneling and as such for HA tunnels (to Azure in my case). The only "downgrade" I'll consider, if this doesn't get worked out completely, is to pull the XG "down" from the rack and put something else in its place.

Nothing like that as far as I can tell. Some of our internal subnets do overlap with subnets that that company on the other end uses internally, but none of those are in this vpn profile. But because of that overlap we do have to nat everything on our end. I originally thought something with the nat'ing might be the cause, but after seeing so many others having the same issue that doesn't seem to be the case. But GES has looked over the nat and subnets and doesn't see any issues with the config as far as those are concerned.

The sad thing is that I flew out to our datacenter (it's on the other side of the country) fully prepared to bite the bullet and downgrade. Support talked me out of it and said that all of these issues should be fixed if I could just upgrade to MR3. I upgraded, they got stuff working, and I thought things were good... Until it stopped working again.

I know your comment was in reply to Matt, but I will reply as well.   :-)   yes I've seen this doc before.  The only thing we're not doing on the cisco side of the config is that our cisco  guy on my team has the ipsec connection setup in transport mode rather than tunnel. Not sure if that matters.   I'm hoping dna will join in this discussion. (I do have a case open that was just escalated to Level 2) about this. 

-Scott