I am getting tired of dealing with this issue and the lack of response from SOPHOS. Your IPsec implementation is, and has been broken due to your choice to NOT allow Anti-Replay configuration. The reality is that throughout this forum there are numerous threads regarding IPsec instability between UTM and other firewalls. Thread after thread of troubleshooting but no answers or resolutions! Many (most) of these issues are very likely attributable to the fact that SOPHOS has hard coded the OpenSwan module to force Anti-Replay and furthermore decided that there is absolutley NO NEED to log anything to do with Anti-Replay. The FACTS: Not all VPN endpoints handle replay protection the same. In MANY cases the ONLY way to get two dissimilar firewalls to negotiate a stable tunnel is to FULLY DISABLE replay protection. It is common practice to fully disable REPLAY protection due to the stability issues it creates. OpenSwan has recognized the issue and enabled a switch to disable replay SOPHOS has repeatedly opted to not implement the ability via WebAdmin or SHELL to adjust or disable replay. SOPHOS has refused to log replay protection messages. When the UTM OpenSwan replay protection triggers, the TUNNEL still is shown (at both ends) as UP but the UTM drops all data packets in both directions (other than the keep-alive, etc for the tunnel itself). THERE IS ZERO LOGGING OF ANY OF THIS ANYWHWERE!!!!! So here in the real world, most net admins build tunnels WITHOUT replay. This means that in many (most) cases Sophos UTMs are not going to be able to negotiate a stable tunnel. This also means that in most of those cases, both the admin and Sophos support are not even going to be able to diagnose the issue, let alone fix it. We have a customer with several UTMs that utilize tunnels to a data center. SOPHOS built a version specific patch for our customer (after I had to repeatedly explain the replay issue to both support and development over a 1 month period). The problem is that that the customer has been stuck on 9.107 for over a year now and I am unable to deploy IPSec tunnels to that (and 2 other) data centers for other customers unless I opt for the OLD firmware. This is a HUGE problem and I can't fathom why it has not been addressed, period.

This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Anti Replay - Is this EVER going to be addressed?

I am getting tired of dealing with this issue and the lack of response from SOPHOS.

Your IPsec implementation is, and has been broken due to your choice to NOT allow Anti-Replay configuration.

The reality is that throughout this forum there are numerous threads regarding IPsec instability between UTM and other firewalls. Thread after thread of troubleshooting but no answers or resolutions! Many (most) of these issues are very likely attributable to the fact that SOPHOS has hard coded the OpenSwan module to force Anti-Replay and furthermore decided that there is absolutley NO NEED to log anything to do with Anti-Replay.

The FACTS:

Not all VPN endpoints handle replay protection the same.
In MANY cases the ONLY way to get two dissimilar firewalls to negotiate a stable tunnel is to FULLY DISABLE replay protection.
It is common practice to fully disable REPLAY protection due to the stability issues it creates.
OpenSwan has recognized the issue and enabled a switch to disable replay
SOPHOS has repeatedly opted to not implement the ability via WebAdmin or SHELL to adjust or disable replay.
SOPHOS has refused to log replay protection messages.
When the UTM OpenSwan replay protection triggers, the TUNNEL still is shown (at both ends) as UP but the UTM drops all data packets in both directions (other than the keep-alive, etc for the tunnel itself). THERE IS ZERO LOGGING OF ANY OF THIS ANYWHWERE!!!!!

So here in the real world, most net admins build tunnels WITHOUT replay. This means that in many (most) cases Sophos UTMs are not going to be able to negotiate a stable tunnel. This also means that in most of those cases, both the admin and Sophos support are not even going to be able to diagnose the issue, let alone fix it.

We have a customer with several UTMs that utilize tunnels to a data center. SOPHOS built a version specific patch for our customer (after I had to repeatedly explain the replay issue to both support and development over a 1 month period). The problem is that that the customer has been stuck on 9.107 for over a year now and I am unable to deploy IPSec tunnels to that (and 2 other) data centers for other customers unless I opt for the OLD firmware.

This is a HUGE problem and I can't fathom why it has not been addressed, period.

This thread was automatically locked due to age.

Parents

0 BAlfson over 10 years ago

If you have an idea for improving the UTM, the best way to get it noticed by Sophos developers is to submit a Feature Request and come back here to provide a link for other forum members to vote for it, too.

Have you asked Support if the rpm they supplied you with a year ago survives any Up2Dates past 9.107, or if the rpm can be safely re-applied after some Up2Dates? I don't think there were any changes to the IPsec package until 9.2. If they don't know, ask for escalation. It may take escalation all the way to the developers, and that might be as long as three weeks.

Most all of my clients are on 9.111, 9.112 or 9.113. I anticipate giving the go-ahead to 9.205-12 this week though.

Cheers - Bob

Sophos UTM Community Moderator
Sophos Certified Architect - UTM
Sophos Certified Engineer - XG
Gold Solution Partner since 2005

MediaSoft, Inc. USA
Cancel
Vote Up 0 Vote Down

Cancel
0 BeanAnimal over 10 years ago in reply to BAlfson

If you have an idea for improving the UTM, the best way to get it noticed by Sophos developers is to submit a Feature Request and come back here to provide a link for other forum members to vote for it, too.
While some folks me say the value in the "vote it up" system of prioritizing feature requests and bug fixes, I find it falls well short in many cases and don't have much faith in their real world effectiveness when compared to the old fashion way. Qualified support engineers should be able to identify issues and pass them to development with there qualification of votes or the number of reported incidents.

This case is a perfect example. This is a serious component implementation issue that affects just about any IPsec user who is not going UTM to UTM. Sadly, almost 100% of those affected would have no idea they were affected. No report, no vote, just an unstable tunnel with no clue as to why.

Have you asked Support if the rpm they supplied you with a year ago survives any Up2Dates past 9.107, or if the rpm can be safely re-applied after some Up2Dates?
I was told that it was for 9.107 explicitly and that the RPM was A) not supported and an install at risk patch for 9.107 only and B) no further RPMS would be developed for  future firmware.

While I would love to tinker around a try to apply the patch to later firmware updates, the UTMs are in a production environment and the process of adding a non-production UTM and having the data center build out a test tunnel will be costly and time consuming. I would much rather the UTM IPsec implementation be fixed instead of spending so many resources playing around with an unsupported RPM that could break with ANY future update.

  I don't think there were any changes to the IPsec package until 9.2.  If they don't know, ask for escalation.  It may take escalation all the way to the developers, and that might be as long as three weeks.
It took months to get them to even recognize there was a valid issue and it became fairly clear that they they had no intention of further dealing with it or future plans to change the functionality or reporting.

Thanks for  the response. My goal here is just to raise awareness with the "regulars", as my official communication with support and development yielded no more than a 1-time, unsupported patch. I feel this is a serious design flaw in the IPsec implementation that could help (and explain) a lot of the problems that folks are having with IPsec rollouts.

I really do like the UTMs we have in the field but this issue is fairly significant for us and the fact that it has been raised several times and ignored is maybe even more significant.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 BeanAnimal over 10 years ago in reply to BAlfson

If you have an idea for improving the UTM, the best way to get it noticed by Sophos developers is to submit a Feature Request and come back here to provide a link for other forum members to vote for it, too.
While some folks me say the value in the "vote it up" system of prioritizing feature requests and bug fixes, I find it falls well short in many cases and don't have much faith in their real world effectiveness when compared to the old fashion way. Qualified support engineers should be able to identify issues and pass them to development with there qualification of votes or the number of reported incidents.

This case is a perfect example. This is a serious component implementation issue that affects just about any IPsec user who is not going UTM to UTM. Sadly, almost 100% of those affected would have no idea they were affected. No report, no vote, just an unstable tunnel with no clue as to why.

Have you asked Support if the rpm they supplied you with a year ago survives any Up2Dates past 9.107, or if the rpm can be safely re-applied after some Up2Dates?
I was told that it was for 9.107 explicitly and that the RPM was A) not supported and an install at risk patch for 9.107 only and B) no further RPMS would be developed for  future firmware.

While I would love to tinker around a try to apply the patch to later firmware updates, the UTMs are in a production environment and the process of adding a non-production UTM and having the data center build out a test tunnel will be costly and time consuming. I would much rather the UTM IPsec implementation be fixed instead of spending so many resources playing around with an unsupported RPM that could break with ANY future update.

  I don't think there were any changes to the IPsec package until 9.2.  If they don't know, ask for escalation.  It may take escalation all the way to the developers, and that might be as long as three weeks.
It took months to get them to even recognize there was a valid issue and it became fairly clear that they they had no intention of further dealing with it or future plans to change the functionality or reporting.

Thanks for  the response. My goal here is just to raise awareness with the "regulars", as my official communication with support and development yielded no more than a 1-time, unsupported patch. I feel this is a serious design flaw in the IPsec implementation that could help (and explain) a lot of the problems that folks are having with IPsec rollouts.

I really do like the UTMs we have in the field but this issue is fairly significant for us and the fact that it has been raised several times and ignored is maybe even more significant.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data