Offloading Encryption (IPSec, HTTPS)

Darcy, may we ask the reason for wanting to off-load?  If you want the Cisco solution, this isn't it. [;)]

What appliance do they have - or is this ASG software on a server of some sort?

Cheers - Bob

One of our clients has hit us up with a requirement to send https traffic from our site to theirs via a VPN tunnel. Casting aside the potential to debate the practicality of this solution, I'm looking for some information regarding Astaro's ability to offload encryption (IPSec for VPN, HTTPS for web security) via their offered hardware appliances or via supported third-party cards.

I wasn't able to find this information via a quick search of the forums. I'm hoping someone here has experience with this.

if you setup ipsec site to site between the firewalls directly the encryption is done on the astaro itself and the decryption done on the receiving machine..if the ipsec is started on a client behind the astaro the encryption is done on the client and the recipient does the decryption..there is no other way encrypted communications work.

Darcy,

When you mean offload encryption, you're thinking to a dedicated crypto accelerator card or through the AES-NI extensions on the newer Intel & AMD processors?

That would have to be a question posed to the folks over in sales as I'm not entirely sure. 

Out of curiosity, how big a pipe are you trying to push data across and how much data are you talking about? Even without crypto cards, the Astaro family is quite capable of handling decently sized VPN tunnels. Cisco to my understanding uses crypto cards because the onboard processor on most cisco routers isn't exactly the most powerful CPU on the market. [;)]

Want to offload to reduce latency from tunnelling. So yes, a dedicated crypto accelerator card is the goal. ASG will be handling reverse proxy, IPS/IDS, and internal ACL between prod/beta/etc networks in a data centre environment dedicated to hosting our application (SaaS model.) ASGs are software licensed v8.3, dual Xeon E5645 (total 24 cores), 16GB RAM in a failover config.

Expected traffic profile once app is scaled up: Busiest times of day see 5 min spikes in the 50-75 Mbps range. Monthly consumption of 10 TB. 10-15K established HTTPS connections with up to 2000 HTTPS requesting over a 5 min period. Access to the application is via dual paths (one private, one public internet) with client desire to wrap in IPSec tunnel for both.

At this point I'm looking for options to optimize our application responsiveness. I've escalated to our vendor as well but also wanted to turn to the community. My experience is dedicated hardware like crypto accelerators

I've received a reply via the vendor initiated request and there is some support for offloading via Intel's AES-NI instruction set. V8 supports SSL acceleration for the Web Application Firewall only. V9 will see full support for IPSec, not sure about other operations/areas. Rev 5 of ASG 425 supports AES-NI offloading. Custom hardware build support can be validated via "cat /proc/cpuinfo | grep aes".

Hi, 50-75Mbps is nothing for a modern CPU, even with 1 CPU core.

BTW, AES is much faster than the other IPSEC crypto algorithms, even without offloading.

Your HTTPS load would be more of a concern, but I'd still think 24 CPU cores should more than handle it.

Most (all?) of the SSL accelerator cards are obsolete these days as CPUs have gotten faster and have surpassed most or all of the accelerators (I looked into this last year).
Astaro used to have some sort of offloading processor in the higher-end appliances, but again, I believe they are obsolete.

Barry

Want to offload to reduce latency from tunnelling. So yes, a dedicated crypto accelerator card is the goal.

offloading via Intel's AES-NI instruction set. V8 supports SSL acceleration for the Web Application Firewall only. V9 will see full support for IPSec.

Good to know!  It would interesting to learn the real-world latency reduction in your IPsec tunnels going from V8 to V9.

Cheers - Bob

If we have the opportunity to do up a "controlled benchmark" I will make every effort to post as time permits.

I am curious, do you have an update on how your benchmarks went?

I am curious, do you have an update on how your benchmarks went?

We've used common sense and a direct circuit to avoid latency via VPN. Sounds overkill but responsiveness of our app is very important.