Anti Replay - Is this EVER going to be addressed?

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

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.

You do realize that this is a user to user forum and not a means of contacting Sophos.  Those that you see assisting and troubleshooting in threads are other end users and resellers.  If you need to contact Sophos staff, as Bob mentions, you need to open a ticket with Support.

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.

You do realize that this is a user to user forum and not a means of contacting Sophos.  Those that you see assisting and troubleshooting in threads are other end users and resellers.  If you need to contact Sophos staff, as Bob mentions, you need to open a ticket with Support.

Scott... I am very aware of what this forum is and that is exactly why I posted here, to make other resellers and and end users aware of the issue.

Regards,

Bill

Bill, after reading the exchange between you and Scott, I decided to actually read and think through your post.  You make some interesting points, but I want to challenge some of the assumptions...

First, just a note that the UTM is based on StrongSWAN, and I don't believe there's a way to disable anti-replay with it.

How widespread is the lack of support for anti-replay or the disabling of it?  In over seven years here, I can't recall a single thread where a UTM/ASG was unable to establish/maintain an IPsec tunnel because of anti-replay.  I did find an unanswered post where the other side had configured the non-use of anti-replay, so that might have been the issue, but the poster did not follow up.

I found a post from over 12 years ago where a cheap Linksys had the ability to enable anti-replay.  Cisco articles mention that disabling anti-replay is the last resort in dealing with old infrastructure because it opens such a big security hole.  I bet this is the issue with the developers, as I know they've refused to allow configuration of Aggressive mode for IKE negotiation.

Are you saying that there's no logging of the dropped packets in the Firewall log?

Cheers - Bob

Bill, after reading the exchange between you and Scott, I decided to actually read and think through your post.  You make some interesting points, but I want to challenge some of the assumptions...

 Thank you [:)]

First, just a note that the UTM is based on StrongSWAN, and I don't believe there's a way to disable anti-replay with it.

 So that is what I thought initially as well. I could go into a lot of detail about the issue we had (I took a lot of note), but in the end if you dig long enough you will find some references in the source and on the developers forums for the vpn stack. 

To make a long story short (if a remember), the Swan defect was identified and a compile time flag was added due to the issue. In fact, it was fixed several times and several times a pig headed developer and/or source branch merge removed the fix. When SW was released, the same pig headedness  prevailed and the replay issue that was fixed in OS was again present in SW  until somebody squeeked enough and it was fixed [again]. Or something along those lines. Like I said, I spent weeks digging into this, as my customer was crippled and screaming.

How widespread is the lack of support for anti-replay or the disabling of it?  In over seven years here, I can't recall a single thread where a UTM/ASG was unable to establish/maintain an IPsec tunnel because of anti-replay.

Your observation is exactly my point. There are plenty of folks who have the symptoms, but because only maybe a handful of network engineers that even know what anti-replay is, they are never properly diagnosed.

Frankly, the only reason I knew about it was because our issue escalated to a Juniper IPsec engineer contracted by our data center. He could not see the replay kicking in on our end, but was positive that it was an issue and when I found out that the stack was Swan (whatever one) he was even more sure. We tried enabling replay on the DC side, but the Juniper settings did not play well with those hard coded into the UTM.

Moreover, he [the Juniper engineer] explained that replay protection, even when properly configured and implemented in a recoverable way (timer based with notification, etc) can be a disaster for highly saturated tunnel due to the inevitability of the number of out of order and dropped packets.

Lastly, consider that any firewall that incorporates the Swan stack will likely play nice with the UTM because both will likely have replay detection enabled by default. So here in UTM land, UTM to UTM or UTM to any other firewall with the OS/SW stack will likely place nice. On the other hand, Cisco, Juniper, etc do not play nice with the Swan stack due to the replay and we both know that the internet is littered with threads regarding IPsec failures between those devices and UTMs and any other endpoint that uses OS/SW.

Cisco articles mention that disabling anti-replay is the last resort in dealing with old infrastructure because it opens such a big security hole.  I bet this is the issue with the developers, as I know they've refused to allow configuration of Aggressive mode for IKE negotiation.

 Yes, that is exactly what they told me and this is where I get more than a little frustrated. 

It is up to the system administrator to set the bar for security with regard to firewall, network, tunnel and other settings. I mean it really is silly for the developers to take such a stand over certain configurable settings when at the same time we get to choose our encryption/hash/cipher combinations (some of which are NOT AT ALL secure), our own password complexity and age requirements, Wifi settings, port forwarding rules, etc.  

As it stands my customer has (3) UTMs tied to a data center (RDS Farm and application servers) and those UTMs are running somewhat outdated firmware that really should be updated for security reasons. I have to ask, what is less secure: A well versed system admin disabling replay on fully secured IPsec tunnel, or a UTM that will be in place for many years without a single firmware update. Honestly, sometimes the tunnel vision (no pun) of the developers can be more than a little ironic. 

I am not asking that the replay protection be ripped out of the device. I am simply asking for the option to disable (or configure) it if needed. If it makes them happy, they can put warnings all over the screen, or require a written release...  

  

Are you saying that there's no logging of the dropped packets in the Firewall log?

 ZERO ZIP NADA.

Bob, the tunnel stays up, it just stops passing traffic. Once replay is triggered NOTHING changes. Both ends show the keep-alive heartbeat and other tunnel specific messaging but the data traffic is simply dropped without logging ANYWHERE. 

To be clear:
There is NOWHERE that shows replay was triggered.
There is NOWHERE that shows the dropped traffic. The ONLY thing we (me, juniper, sophos engineers) could see was the timeouts from pings that never crossed the tunnel.