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.



Published Jan 05, 2017
Version 1.0

Was this article helpful?


  • Harry1's avatar
    Icon for Nimbostratus rankNimbostratus

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


  • sure, we could do a FireEye session, we'll add that to the queue. Thanks for the idea.


  • Hey 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. :(


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


  • 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. :)