Release of v17 MR-2?

For users continuing to see IPsec site-to-site VPN issues on v17 MR-3, please contact Support and open a ticket to provide logs & report possible BUG. Once you do please provide me with your case ID so I can be sure that the case is escalated. 

For non-licensed users, please share or DM me the following information: 

• logfiles from the time frame when the Problem happens (/log/charon.log)
• screenshots of the Connection config
• screenshots of the Policy used in the Connection
• charon related coredumps from /var/cores (if any)

We appreciate all your feedback.

Thanks,
Karlos

I've had case #7758347 open for a while trying to work on this. Unfortunately I replaced a Cisco ASA with a Sophos appliance already running v17 on the other side of the country. Debating whether or not to wait for a fix or go ahead and fly out there and go through the process of downgrading to 16, which essentially does a factory reset, or just stick the ASA back in place and ask Sophos for my money back. I have another identical Sophos UTM running at another datacenter in another state with v16 that isn't experiencing any of these issues.

Our issue is that every few hours one of our main ipsec tunnel will drop and doesn't come back up unless someone resets it on our end. My current workaround is that I have Solarwinds monitoring devices on the other end of the tunnel. When Solarwinds loses that connection it kicks off a script using Devolutions RDM to open an ssh session to the UTM and restart the VPN service. This obviously isn't a doable workaround for everyone.... and still causes a lot of issues for us since we have a lot of realtime data coming across that tunnel. So every time it drops is trouble.

MR2 and MR3 cause the tunnel to completely stop working. So right now I'm stuck on MR1 because that seems to be the only spot where the tunnel at least works. 17 GA had a bug that caused the UTM to become unresponsive and we kept having to do hard resets on it, by shutting off power to it from the PDU it's plugged into. But the tunnel seemed to be stable on GA. MR1 seemed to be where the IPSEC issues started for me. But I'm in between the rock (UTM becoming completely locked up) and the hard place (the tunnel randomly dropping).

I've had case #7758347 open for a while trying to work on this. Unfortunately I replaced a Cisco ASA with a Sophos appliance already running v17 on the other side of the country. Debating whether or not to wait for a fix or go ahead and fly out there and go through the process of downgrading to 16, which essentially does a factory reset, or just stick the ASA back in place and ask Sophos for my money back. I have another identical Sophos UTM running at another datacenter in another state with v16 that isn't experiencing any of these issues.

Our issue is that every few hours one of our main ipsec tunnel will drop and doesn't come back up unless someone resets it on our end. My current workaround is that I have Solarwinds monitoring devices on the other end of the tunnel. When Solarwinds loses that connection it kicks off a script using Devolutions RDM to open an ssh session to the UTM and restart the VPN service. This obviously isn't a doable workaround for everyone.... and still causes a lot of issues for us since we have a lot of realtime data coming across that tunnel. So every time it drops is trouble.

MR2 and MR3 cause the tunnel to completely stop working. So right now I'm stuck on MR1 because that seems to be the only spot where the tunnel at least works. 17 GA had a bug that caused the UTM to become unresponsive and we kept having to do hard resets on it, by shutting off power to it from the PDU it's plugged into. But the tunnel seemed to be stable on GA. MR1 seemed to be where the IPSEC issues started for me. But I'm in between the rock (UTM becoming completely locked up) and the hard place (the tunnel randomly dropping).

Hi Ryan,

Thank you for that. Reviewed your case and as you've mentioned, understandably rolled back to MR-1 due to the instability issues. To escalate the case, it will be necessary to be on MR-3 so we can extract the debug information necessary to submit to our Escalation/Development team. 

We will update this thread for any progress on this issue.

Thanks for your patience.

Best,
Karlos

That is simply not an option. The majority of our companies business depends on this one vpn tunnel being up and running. From what I'm told from our business team we lose roughly $1,000 every minute that it's down. Unfortunately the other end of the tunnel is managed by a company that we are partnered with, so we don't manage it and do not have any say on replacing it. They are running an ASA that does not support ikev2. They have that ASA scheduled for replacement but it's not for several more months. I cannot upgrade to MR3, break the tunnel, send our company into a financial tailspin, and likely lose my job. No thank you, I'll let another user with this issue take that bullet. I am not going to knowingly upgrade to a broken firmware version.

*edit*

The "fix" that sophos' engineers should be working on right now is a graceful downgrade path back to 16 that will leave your config intact. Get users off of this broken version until sophos has fixed it and thoroughly tested it.

Same issue here, and your comments resonate with me too.

Thanks everyone who have provided me their Case ID's. I have reviewed and forwarded these cases over to the relevant team. I continue to urge customers who are experiencing this issue and have not opened a ticket to please do so.

In the meantime, please review our KB Article on recommended IPsec configuration for v17: Sophos XG Firewall v17: Recommended configuration for IPsec profile

Best,
Karlos

Thanks Karlos, but I suspect that that link is not helpful to the majority of users having these issues. Many of us have no say in what device or configuration is used on the other end of the tunnel. In many cases I've seen, the device on the other end is simply unable to run IKEV2. Of course upgrading everything to IKEV2 is preferred, but this is the real world and sometimes we in the tech industry have to use less than ideal security settings in order to keep business running. IKEV1 is still a broadly used standard, and I am sure most everyone is working on moving away from it, but while they're making that move it is crazy to simply take it out completely. When you're getting ready to stop supporting a standard like that there needs to be a year notice at a minimum, post an End-of-Life, set an exact date when Sophos will no longer support IKEV1. Don't just kill the functionality and tell users after they've upgrade "Oops! I guess you'll have to switch now!"

So now here's the new big question in my mind, and I'm sure the minds of everyone stuck with this issue. With Sophos' announcement of a patch for the Spectre/Meltdown vulnerability, will the maintenance release that contains that patch either require MR3 to be running, or be a rollup that contains MR3? Because right now I'm thinking that it's going to come down to us being between the rock and the hard place of patching a critical hole or breaking a critical vpn that our company depends on. If the upcoming patch is going to break that I am going to need to go ahead and schedule a flight out to our datacenter to roll back to 16.5. So if any Sophos employees have any insight into this it would be extremely helpful.

Again, I would strongly recommend that Sophos apply some resources to creating a smooth downgrade path back to 16.5 since their affected customers are now in a very dangerous predicament. I may be the only one who feels this way, but this issue has made me want to throw all of my Sophos UTM's out the window, and depending on how Sophos continues to handle this issue I am becoming very unlikely to continue running Sophos in our environment when our renewals come back up. 

HI all,

And finally i've got the WHY.....

Sophos has migrated the ipsec engine to https://strongswan.org/ which is free.

There is no hazard, and that why every of us was asking by support to completely recreate the ipsec profiles. We know that after recreating everything it's not stable too.

Today i upgrade a v15.1 to v16.5.8 and ipsec vpn are still... perfectly STABLE !!! (without recreating anything)

I need V17 NOW (dns wildcard objects, IKEV2, object group for firewall) and i won't/can't recreate anything on my configurations.

PLEASE SOPHOS just give us a functionnal release !!!!!!

Yes they moved from openswan in v16 to strongswan in 17. The frustration we're all experiencing does not center around the ipsec engine but rather in whatever transitional code was required to bring existing connections and profiles from openswan to strongswan. I won't pretend to know what is involved exactly but I would assume that when looking at a firmware upgrade you would want something that translates your current config into whatever the new firmware is built on.

If you (Sophos) can't create such transitional code, at least let us know as part of the upgrade process we'll need to reconfigure some of our settings (e.g. completely delete and reconfigure ipsec profiles and connections).

That was not the case for me Matt. This was a new install. I was not running 16 at any point on this UTM. I have also recreated the tunnel many times with support, and continue to have the issue.