1.6. SSL Orchestrator Quickstart

The F5 SSL Orchestrator provides a workflow-driven configuration:

  • Start by selecting a desired topology. This is defined as the method by which traffic is consumed:

    • For a Transparent Forward Proxy topology configuration, where the BIG-IP accepts outbound traffic as a routed path to the Internet, you can start at section 2.3.


    • For an Explicit Forward Proxy topology configuration, where the BIG-IP accepts outbound traffic as an addressable explicit proxy endpoint, you can start at section 2.4.


    • For a Reverse Proxy topology configuration, where the BIG-IP accepts inbound application traffic, you can start at section 2.5.


    • For an Existing Application topology configuration, where the SSL Orchestrator security policy can be attached to an existing reverse proxy application virtual server, you can start at section 2.6.


    • For a Layer 2 topology configuration, where the BIG-IP acts as a physical bump-in-the-wire for inbound or outbound traffic flows, you can start at section 2.7.

  • Once the topology is selected, you will define one or more security services to attach to the SSL Orchestrator. A security service is the external component (appliance, module) that receives decrypted traffic and performs layered security functions on that traffic. Security services are independently addressable from the SSL Orchestrator, and a “service” represents one or more “devices” of the same type in a load-balanced pool.

    • An inline layer 2 security service is itself a bump-in-the-wire and accepts decrypted traffic into one interface and returns that traffic on another interface. Passive inline security devices normally fit into this category. Detailed information for this service type can be found in section 3.1.


    • An inline layer 3 security service is a layer 3 device that accepts routed traffic and then routes that traffic back to the BIG-IP. An Intrusion Prevention System (IPS) or Next Generation Firewall (NGFW) normally fall into this category. Detailed information for this service type can be found in section 3.2.


    • An inline HTTP security service is a proxy device. It can either be a transparent or explicit proxy. Detailed information on this service type can be found in section 3.3.


    • An ICAP security service is any device that conforms to RFC3507 for consuming traffic. Detailed information on this service type can be found in section 3.4.


    • A TAP security service is a passive receive-only device. An Intrusion Detection System (IDS) is a typical example of a TAP service. Detailed information on this service type can be found in section 3.5.

  • Once the services are defined, create one or more service chains which contain ordered sets of security services which traffic will flow to for inspection.


  • Next, the Security Policy defines the set of traffic matching criteria, and corresponding actions. Security policies are described in more detail in section 4.3. A matching traffic pattern defines the following actions:

    • Allow or Block the traffic.


    • TLS intercept (decrypt) or bypass decryption.


    • Assign the traffic to a specific service chain.

  • To complete the workflow, define any additional traffic consumption characteristics on the Interception Rules page, and finally, define how traffic leaves the BIG-IP on the Egress Settings page.