Site to site IPSEC - Astaro -> Juniper

Paul,

The UTM has an IPsec feature called "Anti Replay" enabled. It is not configurable. (See NOTES below). You can try enabling replay protection in the Juniper side and see if that helps, it may or may not. If you have replay DISABLED on the juniper side, then you have ZERO change of building a stable tunnel.

I have no idea of this is your problem, but I know for sure that it is an issue with default juniper settings, were replay protection is disabled.

The symptoms are pretty simple to recognize. You can get the tunnel established and it will pass traffic as expected, until that traffic becomes congested. TCP Packets, doing what TCP packets do, will start to arrive out of order. At some point the UTM IPsec stack will inspect the traffic looking for the packet numbering, to ensure that there is no MIM attack but it will find no numbers (or find an unexpected result) and will BLOCK the tunnel WIHTOUT ONE BIT OF LOGGING. No mind you, the tunnel will not collapse, it will stay up and connected, but it will simply not pass any user traffic and instead will only pass the heartbeat and other IPsec keep-alive data. 

You see Anti-Replay is a little understood compile time configurable feature of the OpenSwan (and derivatove) IPsec packages. It is a security option (on by default) to prevent out of order (man-in-the-middle) type of packet attacks against the tunnel. It is a mess to get working between different vendors, so as a rule we disable replay protection when building IPsec tunnels between dissimilar endpoints.

Here is the rub, you can't turn replay protection off on a UTM IPsec tunnel. The brain trust in development feels that it is a "security risk" to allow an end user to turn it off (laughable at best). At the same time, they also refuse to turn up any kind of logging to indicate that Replay Protection has kicked in OR that the tunnel traffic is being blocked by said protection.  THIS IS A HUGE FAIL on the part of SOPHOS, any what you slice it and has been ignored for a long time. In fact, there are plenty of unsolved IPsec problem threads here that can easily be attributed to this issue, except few folks know about it and development refuses to address it.

So not sure if that is your problem but it is worth a look...

BeanAnimal, thanks for helping.

A little bit of a correction to your comments, most of which are spot on.  The UTM's IPsec implementation is based on StrongSWAN, not OpenSWAN.  The ability to adjust Anti-Replay in StrongSWAN only occurred in Charon, after Pluto, the daemon currently in use in the UTM

 Many of us have pushed for upgrading to Charon because of IKEv2 and better compatibility with Azure.  Unfortunately, that hasn't been listed on the road map for 2015 development.

Cheers - Bob

For completing this case, here you'll find the corresponding Feature Request, which everybody should push, who is not happy with the current situation :-)

BeanAnimal, thanks for helping.

A little bit of a correction to your comments, most of which are spot on.  The UTM's IPsec implementation is based on StrongSWAN, not OpenSWAN.  The ability to adjust Anti-Replay in StrongSWAN only occurred in Charon, after Pluto, the daemon currently in use in the UTM

 Many of us have pushed for upgrading to Charon because of IKEv2 and better compatibility with Azure.  Unfortunately, that hasn't been listed on the road map for 2015 development.

Cheers - Bob

Thanks for the clarification Bob. I am not sure what build 9.106 uses, but we were provided a ONE TIME compile, delivered via RPM with replay protection disabled. If I remember, the replay window and flag were in fact adjustable in Pluto, but not documented. I think the flags were added way back in OpenSwan and further branches kept them, with or without documentation. Even the project contributors appear to be confused about the feature (from what I have read of the little info that is out there). Nonetheless, we applied this patch to multiple UTMs connecting a customer to a Juniper firewall at their DC. 

We were told explicitly that the patch would ONLY work with 9.106, that further support on this matter would be denied and that any firmware upgrade would likely break the patch, at which point development would refuse to build a new version. 

While that was more than a little frustrating, the icing on the cake was the response to our request for a shell option to toggle the feature, something extremely easy to add. Here is (one) of the responses:

Because this is a security feature we will not disable that in general. What we can provide you is for a test a patched version of strongswan where this feature is disabled manually. But we will not re-build that rpm again and again after each update of the UTM. So you have to stay on that version where we build the strongswan.

 So the developers think, we as admins, are too stupid to adjust tunnel security settings (well of course other than ALL of the typical Phase 1 and 2 paramaters, keys and cryptos). In the same breath, where they deny a needed feature due to SECURITY concerns they tell us we need to leave the customer on firmware that is/was known to have multiple security issues and is further unpatchable.  Furthermore, they have been made acutely aware of the IkeV2 situation and ignored the SECURITY benefit. And lastly, said development team has further refused to even bother enabling logging of the Replay Protection status flags, so we still have no clue when (if) replay (a security feature in their words) is kicking in to (protect?, cripple?) the IPSec tunnel. 

Look, I am not perfect and certainly make mistakes and bad decisions, but at least in my opinion, given the context, this is pure arrogance on display from development level and poor management from a corporate level. As you have seen by my other posts, my frustration is certainly at a high level. This latest firmware disaster that has dragged on for a few months has really started to sink in and re-irritate issues like this. As rude as it sounds, at this point I see these guys as clowns disguised in developer suits, managed by clowns in business suits, all participating in a three ring circus. 

Sorry (not so much) for the rant. As Always Bob, thank you for your insightful input and continued help.

For completing this case, here you'll find the corresponding Feature Request, which everybody should push, who is not happy with the current situation :-)

Even if they upgrade, they will (at least based on every previous interaction) refuse to address the Replay issue. At least to this point, they have made that patently clear in several responses.