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

 

Published Jan 05, 2017
Version 1.0

Was this article helpful?

5 Comments

  • Harry1's avatar
    Harry1
    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. :)