1.3. Terminology

There are some important terms and concepts introduced with the F5 SSL Orchestrator. The following is a short list of terminology used throughout this guide.


The term “layers” loosely refers to the layers of the OSI model, which is important to understand when talking about networking products. In particular for SSL Orchestrator discussions,

Figure 2: Layers of the OSI model

Layer 7 (L7) references the application layer, for example, HTTP. One of the key features of F5 SSL Orchestrator is to provide layer 7 visibility by decrypting traffic flows.

Layer 4 (L4) applies to the point-to-point connection between devices and will typically be TCP (connection-based) or UDP (connection-less).

Layer 3 (L3) is analogous to IP-based device, that is, a device that has IP addresses and is commonly involved in the routing of traffic.

Layer 2 (L2) is generally the absence of IP addressing, that is, a device that does not have IP addresses and typically bridges traffic between two interfaces.

Forward Proxy and Reverse Proxy

At its core, F5 SSL Orchestrator uses a full proxy architecture that maintains separate connections for the client and server sides of a conversation. It is this distinction that provides the flexibility to support the breadth of topology modes and security service types. A proxy is typically defined as either forward or reverse, and there are subtle yet important differences between these.

  • A forward proxy is associated with outbound traffic, usually some finite set of internal users attempting to access an infinite number of external resources (i.e. the Internet). In SSL Orchestrator, the proxy type also defines who owns the encryption keys. In a forward proxy, the remote resource owns the encryption keys, so SSL Orchestrator must re-issue (forge) a local copy of the remote server’s certificate to the internal client. The internal client must then trust the local certificate authority of those re-issued certificates. Forward proxies will either be routed to (L3 topology mode) or addressed directly (explicit proxy topology mode).

  • A reverse proxy is associated with inbound traffic, usually some infinite number of external clients (i.e. clients on the Internet) attempting to access a finite set of internal resources. In SSL Orchestrator, the proxy type also defines who owns the encryption keys. In a reverse proxy, the F5 BIG-IP device owns the encryption keys and performs direct and explicit decryption with these keys.


A topology is an entry point for network traffic into SSL Orchestrator, and is represented by the following SSL Orchestrator topology ‘modes’:

  • Outbound Layer 3 Transparent Proxy (L3) - this forward proxy topology mode is a layer 3 routed hop within the network. Network traffic is routed outbound through this topology mode. Clients will typically access this topology mode as a function of a gateway setting on the client, by configuring routes on routing devices, via policy-based routing, or via WCCP where applicable.

  • Outbound Explicit Proxy - this forward proxy topology mode implements an explicit HTTP proxy configuration. Clients will normally access this topology mode via browser explicit proxy settings, proxy auto-configuration (PAC) or WPAD configuration settings.

    The primary differences between a transparent and explicit forward proxy are:

    • Clients are specifically configured to use an explicit proxy, as it is usually statically (or dynamically) assigned in the client user-agent (i.e. browser). Clients using a transparent proxy typically do not have any specific configuration related to the transparent proxy because traffic is delivered to the proxy by routes within the network.

    • In an explicit proxy request, the destination address is the explicit proxy itself. In a transparent proxy, the destination address is typically the real remote address.

    • In an explicit proxy request, the client does not perform DNS resolution of the destination address. This is performed by the explicit proxy on behalf of the client. In a transparent proxy, the client must perform its own DNS resolution.

  • Inbound Layer 3 (L3) - this reverse proxy topology mode is a layer 3 configuration analogous to traditional F5 BIG-IP application delivery scenarios, where external/remote clients access internal load balanced resources through an F5 BIG-IP system. This SSL Orchestrator topology mode augments traditional load balancing functionality by adding decryption and dynamic service chaining features.

  • Inbound and Outbound Layer 2 (L2) - this “bump in the wire” topology mode is a layer 2 configuration, where the SSL Orchestrator system presents no IP addresses on its external interfaces and is not directly involved in the routing of packets. This topology mode is essentially a physical presence on the wire. Inbound and outbound L2 topologies are differentiated by which interfaces they listen on, and in which direction network traffic is to be decrypted and inspected.

  • Existing Application - there are scenarios where an F5 BIG-IP LTM reverse proxy application already exists, and the security administrator wishes to add dynamic service chaining to that application. As a function of the LTM virtual server configuration, SSL processing and traffic management is already defined. The Existing Application topology mode skips the SSL and traffic management settings found in the Inbound L3 topology workflow to produce services, service chains, and a security policy. The security policy can simply then be attached to the LTM virtual server to add service chain orchestration to third-party security products.

Topologies represent the way SSL Orchestrator consumes network traffic, and it is possible to have multiple topology modes deployed on the same system. It is also important to consider that topologies and services (introduced below) are independent of one another. For example, a layer 2 topology can possess layer 3, HTTP and ICAP services in its inspection zone.


Some topology options may not be available on all platforms:


The term inline refers to a device that has physically or logically separate inbound and outbound traffic paths. Traffic enters one interface and exits another. This term is used within SSL Orchestrator to define layer 2, layer 3 and HTTP security services to which SSL Orchestrator passes decrypted traffic to. SSL Orchestrator passes decrypted traffic to one interface of the device, and that traffic flows through the device and exits another interface (again, physical or logical) to return to the SSL Orchestrator.


The term service represents a single security product (ex. FireEye NX, Palo Alto NGFW, McAfee DLP, etc.). However, a service and a “device” refer to different things in SSL Orchestrator. A device in this case is a single appliance, while a service represents the load balanced and monitored set of like devices. For example, a single FireEye service might define a set of multiple FireEye NX appliances (devices). SSL Orchestrator allows administrators to create many services, each containing a number of like devices.

Services fall into five categories based on how they consume network traffic. Almost all modern security products today fit into at least one category, but in some cases a security product can be configured to operate in different modes. SSL Orchestrator supports the following service types:

  • Inline Layer 3 - an inline L3 device is an IP-based device that can route. It is “inline” in the sense that network traffic enters one (physical or logical) interface and routes out another. In this case, the SSL Orchestrator routes to it, and it routes back.

  • Inline Layer 2 - an inline L2 device does not have IP addresses and does not participate in routing. It is effectively no more than a physical presence on the wire.

  • Inline HTTP - an inline HTTP device is a subset of inline L3 devices, except that it is a proxy-type device. Proxy-type devices can be transparent or explicit, but the most important difference between HTTP and L3 devices is that HTTP devices, as a function of proxying, change the TCP flows. In particular, a proxy device will always minimally change the source port but may also change source and destination addresses.

  • ICAP - an ICAP device is one that adheres to RFC 3507 specifications. ICAP itself is a payload encapsulation protocol and is often used to encapsulate payloads to various types of services, including DLP and malware detection products. In this case SSL Orchestrator is the ICAP client, encapsulating HTTP request and response payloads to an ICAP service.

  • TAP - a TAP device is a passive receive-only service. Intrusion Detection Systems (IDS) are commonly deployed as TAP, and simply receive an out-of-band copy of the network packets.

Service Chains

A service chain is a logical grouping of services in a defined order through which SSL Orchestrator processes traffic. Security policies match traffic flow conditions, which then assign flows to service chains. The service chain then orchestrates the traffic through the defined set of services in the defined order. An SSL Orchestrator service chain is uniquely different than the “daisy chain” approach of other SSL visibility products. It may be useful to conceptualize a service chain as the opposite of a daisy chain.


Figure 3: Daisy chaining devices

In a daisy chain, traffic flows through each device in the chain directly - out of the first device, directly into the second device, from there directly into the third device, etc. before returning to the SSL visibility product. In such a daisy chain architecture the devices are usually wired directly together, such that all devices see all traffic.

The following are typical characteristics of a daisy chain:

  • If a device in the daisy chain is not designed to inspect some type of traffic, it still must at least pass that traffic through, which counts against its capacity.

  • If a specific throughput requirement is needed for the solution, then all devices in the daisy chain must support that throughput.

  • As these devices are usually wired together, it becomes challenging both to scale (i.e. load balance) and to make changes or perform maintenance without requiring downtime.

In the SSL Orchestrator service chain model, all services are connected (physically or logically) to SSL Orchestrator. The service chain model improves over the daisy chain model in the following ways:

  • If some services are not designed to inspect some types of traffic, a traffic policy can simply send traffic to services that are interested, bypassing those that are not. For example, the policy could be configured to only send outbound HTTP traffic to a HTTP proxy device.


Figure 4: Service chaining services

  • If a specific throughput requirement is needed for the solution, but not all traffic needs to go to all services, then not all services have to scale at the same rate.

  • As these services are independently orchestrated, it becomes easy to scale and perform maintenance (i.e. add/remove devices from individual service pools), without incurring any downtime.

Security Policies

Security policies are the set of rules that match traffic patterns. When a rule condition is matched, it assigns a set of actions, including:

  • Allow or reject the traffic

  • Intercept (decrypt) or bypass decryption

  • Assign the traffic to a service chain

Security policies can match on any number of traffic conditions, minimally including:

  • Source and destination address/subnet

  • Source and destination port

  • URL filtering and IP intelligence reputation (add-on subscriptions)

  • Host and domain name

  • IP geolocation

  • Application layer protocol

Dynamic Service Chaining

Dynamic service chaining is the concept that combines service chains and traffic policies. Traffic policies allow or block, intercept or bypass, and assign traffic to different service chains and different sets of security services dynamically.


Figure 5: SSL Orchestrator dynamic service chaining

Inspection Zone

An inspection zone refers to the network region between decryption and re-encryption operations where cleartext data is available for inspection. SSL Orchestrator decrypts traffic once, dynamically orchestrates that traffic to the set of defined security services, and then re-encrypts.

F5 Guided Configuration for SSL Orchestrator

The Guided Configuration for SSL Orchestrator is designed to guide you through setting up a particular use case on the SSL Orchestrator system. Each template requests minimal input and provides contextual help to assist you during setup. The current version displays on the landing page.