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...

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...