We have over 60 XGs in Azure that terminate 150+ B2B ipsec tunnels with our customers, many having Cisco ASAs on the remote side. One thing that is killing us and frustrating our customers is that if our XG ends up as the ISAKMP responder, the XG relies on the Initiator side to initate all Child_SAs.
This is wrong, Responder/Initator is only valid for IKE_AUTH, not for child sa negotiations. The reason is that Ciscos only initiate Child SAs on traffic, while XG (when in initiator) create all SAs immediately. So when our systems try to extract data from their systems, the connections fail until we reset the tunnel (after the customer has reported the issue), in the off-chance that we become the initiator. As responder, XG will not create SAs on traffic, which is the root of the problem.
StrongSwan has the ability to act like the Cisco and initiate on traffic using "traps". Why is this option missing from the XGs? The current implementation in XG is flawed. Initiate or Respond-Only are not 100% compatible with Cisco for the reason I mentioned above. Does anyone have any idaes to get around this, short of having our customers turn on SLA Monitor (some tunnels having 50+ SAs).
I think getting Sophos to even think about fixing their implementation is like moving a mountain. (trying to get our company to look at another vendor as replacement, but in the meantime..)
Thanks
This thread was automatically locked due to age.
