Release of v17 MR-2?

so better to be safe with SFOS 16.05.8 MR-8, as the 17 still not stable, I was going today to update HW-SFOS_17.0.2_MR-2.SF300-116 but it seems still too many people complain about un stability 

My device recently came with 17 MR-3 and I tried for many weeks, and tons of hours trying to get Ikev1 to work with another companies Cisco ASA which doesn't have Ikev2. Worked with sophos support etc, and they helped me to get it sort of up. But after a restart, it wouldn't come back up or did but flakey. I tried recreating policies and sometimes that only worked for a few minutes, hours or days. I couldn't run my customer's network on that. I gave in, as I was pretty close to calling it quits with Sophos and just getting a Meraki, but on the last night, as soon as I installed 16.05.8 MR-8 from mysophos, tunnel came right up with no fuss. So far 2 days going strong.

Ryan,

yes i would advise you to downgrade to v16.5 mr8 which running very fine !

Be carreful when you downgrade, you will have to reconfigure everything from scratch. but this will works.

I can confirm i am totally happy with v16.5 mr8, in many scenarios (IPSEC, multiwan, ssl client or site to site...) and i am actually a bit SAD about v17, now in its 4th "stable" release, and still not stable at all.

Totally agree with you, I'm very disappointed with V17

When I did downgrade, I was thinking that I'd be able to restore the backup config onto the old firmware, but alas it didn't work. Luckily my configuration is still pretty basic. You might get away with doing an Export/Import instead of the "full config"? But this I don't know for sure. Take a lot of screenshots etc. but also, you can always go back to your 17.x firmware and config with a click as long as you don't overwrite that one on the disk.

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).

Thanks Karlos,

My case id/Service request number is: 7819367 

Thanks,

-Scott

I want to add that we had to switch back to a cisco device at this remote location today because of lack of stability on the sophos.  If you need somethign from the system it will have to wait until tomorrow.  I did upload the charon.log file from yesterday as part of my case though.

-Scot

Hi Scott,

Thank you for that. Reviewed your case & as agreed upon, please give us a call next time the tunnel goes down so we can gather the necessary debug information we'd need to submit for escalation.

Best,
Karlos