Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 26 subscribers
  • Views 8796 views
  • Users 0 members are here
Options
Suggested
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 configuration

Abhi Saini

I saw a couple year old post on UTM about anti-replay not being configurable. Is this still the case on XG? I'm on 16.01.2 and our IPsec tunnel is not stable. The peer we are connecting to is using a Fortinet device. We have a feeling anti-replay might be an issue and I need to ensure it is turned off.



This thread was automatically locked due to age.
Parents
  • 0

    Abhi,

    Anti-replay attacks can be protected using AH and ESP inside the IPsec tunnel.

    XG support both Transport and tunnel mode.

    UTM supports only tunnel mode.

    Regards,

  • 0 in reply to lferrara

    Thanks for the reply.  That's good info to have. I'm actually interested in making sure it is turned off. Is there a way to check to make sure anti-replay is turned off?

  • 0 in reply to Abhi Saini

    Abhi,

    I think that you cannot disable it because it is something built inside the IPsec protocol and not with the XG itself.

    However you should not disable anti-replay attack. Replace the other end if it does not support anti-replay attacks.

    Regards

  • 0 in reply to lferrara

    It's definitely possible to disable anti-replay on Cisco, Fortinet, and other enterprise grade devices. I agree that it is a good feature to keep enabled but sometimes other security measures are in place and anti-replay is not needed.

    In my case, I need to turn it off. It's able to be turned off on the other end and I don't think it's logical to simply replace the other end when anti-replay is not a required sub-protocol of IPsec, especially when the other end has tunnels with hundreds of clients and none of have issues like this.

  • 0 in reply to Abhi Saini

    There are not other features like anti-replay attack.

    I am not sure if you can disable anti-replay settings.

    Open a feature request on ideas.sophos.com

    Regards

  • +1 in reply to lferrara

    You are correct. I spoke with Sophos and they confirmed Anti-replay is turned on and it is "not configurable via GUI and also not supported via CLI"

    A little unfortunate but at least the mystery is solved! 

    Device and FW at time of solution: XG210 (SFOS 16.01.2) 

  • 0 in reply to Abhi Saini

    This is EXACTLY the reason that we moved most of our customers away from Sophos completely. 

    The reality with "replay" is that no two vendors treat it exactly the same, and therefore it rarely works well between vendors.

    A large percentage of IPsec tunnel instabilities can actually be traced back to replay problems, yet very few network admins or vendor support teams understand how to recognize or diagnose the problem. This is because most don't understand it and most appliances don't properly report replay issues. The issue is big enough that the "real" firewall vendors (The Junipers and Ciscos of the world) have all provided a means to disable replay protection. Yet Sophos' "we know best" arrogance has ignored the issues since the Astaro acquisition.

    In fact, after several escalations directly to the top, we have been told that replay is a "Security Feature" that Sophos WILL NOT by any means allow to be disabled via GUI or CLI. That is pure BS, like any other aspect of the IPsec protocol, it should be configurable. The underlying StrongSwam and OpenSwan stacks allow the flag to be set, but Sophos refuses to add a setting for this flag. 

    Let's put it this way. Got an IPsec tunnel that is UP but will not pass packets?  Replay has likely kicked in, but there is no Sophos logging or alert to highlight the issue. In fact, the Sophos products don't log any aspect of replay.

    You head that right, when replay protection kicks in, the tunnel is NOT dropped by the Sophos, there is NO reporting or alert. The packets simply just stop flowing. As mentioned above, this issue has been escalated numerous times over the last 6-7 years to no avail.  

Reply
  • 0 in reply to Abhi Saini

    This is EXACTLY the reason that we moved most of our customers away from Sophos completely. 

    The reality with "replay" is that no two vendors treat it exactly the same, and therefore it rarely works well between vendors.

    A large percentage of IPsec tunnel instabilities can actually be traced back to replay problems, yet very few network admins or vendor support teams understand how to recognize or diagnose the problem. This is because most don't understand it and most appliances don't properly report replay issues. The issue is big enough that the "real" firewall vendors (The Junipers and Ciscos of the world) have all provided a means to disable replay protection. Yet Sophos' "we know best" arrogance has ignored the issues since the Astaro acquisition.

    In fact, after several escalations directly to the top, we have been told that replay is a "Security Feature" that Sophos WILL NOT by any means allow to be disabled via GUI or CLI. That is pure BS, like any other aspect of the IPsec protocol, it should be configurable. The underlying StrongSwam and OpenSwan stacks allow the flag to be set, but Sophos refuses to add a setting for this flag. 

    Let's put it this way. Got an IPsec tunnel that is UP but will not pass packets?  Replay has likely kicked in, but there is no Sophos logging or alert to highlight the issue. In fact, the Sophos products don't log any aspect of replay.

    You head that right, when replay protection kicks in, the tunnel is NOT dropped by the Sophos, there is NO reporting or alert. The packets simply just stop flowing. As mentioned above, this issue has been escalated numerous times over the last 6-7 years to no avail.  

Children
No Data