Site to site IPSEC - Astaro -> Juniper

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

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.

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.