Lightboard Lessons: Air Gap Architectures
In this episode of Lightboard Lessons, Jason covers a couple deployment options for routing traffic through an IPS tier while maintaining source IPs. The first option compresses the external and internal legs of the air gap solution onto a single BIG-IP (or pair) by using route domains. The second option splits the external/internal requirements onto separate BIG-IPs to allow for isolated vertical security zones.
Resources
- SSL Intercept iApp
- SSL Intercept Deployment Guide
- IPS Bridged Air Gap Solution (Lightboard Lesson | Article)
Published Jan 05, 2017
Version 1.0
JRahm
Admin
AdminJRahmAdmin
Admin
Harry1Nimbostratus
Hello Jason.. can you please publish a session for fireeye and f5 integration? also want to understand the difference between both deployment : fireeye+f5 and airgap ssl..
- JRahm
sure, we could do a FireEye session, we'll add that to the queue. Thanks for the idea.
Carlos_PessetHey Jason,
The 1st BigIp(ingress) will have a client_ssl and a server_ssl configured, right?
The 2nd big ip will need a server_ssl as well only if a need to reencrypt the traffic?
I'm not sure if I get this part. :(
- JRahm
1st BIG-IP is offloading and not re-encrypting so the IPS layer can see the traffic, so it would only have a clientssl profile.
2nd BIG-IP (if required) would re-encrypt the traffic for delivery to the server, so would only need a serverssl profile.
- Carlos_Pesset
Thanks for the answer Jason.
I was making a huge confusion between airgap concepts for forwarding ssl intercept traffic and reverse ssl proxy traffic.
For forwarding I believe that yes, both client and server_ssl are needed in the ingress(internal) LTM and a a server_ssl for the egress(external) LTM.
For reverse proxy is just as you explained: ingress(outside) LTM with client_ssl and egress(internal) with server_ssl.
At least this is what I've seen reading some deployment guides. :)
