Implementing SSL Orchestrator - F5 TMOS Configuration

F5 TMOS Configuration


This article provides an overview of the configuration items created by the SSL Orchestrator when creating a topology through the guided configuration tool. This article is provided for administrators familiar with BIG-IP constructs such as Virtual Servers, Pools, Route Domains, etc.


The following figure shows the policy created via the guided configuration tool:





The actual configuration resulting from the topology pictured above results in the following Virtual Server objects:



  • The “-in-t-4” VIP corresponds to the client-facing traffic ingress listener (how traffic is consumed into SSLO)
  • The “-dlp-tp-4” VIP is an internal virtual that is the entry point to a defined ICAP security service. This profile contains the Adapt profiles that point to the respective “-dlp-req” and “-dlp-rep” virtuals.
  • The “-dlp-req” and “-dlp-rep” VIPs are the internal ICAP VIPs that pool to the respective ICAP device(s).
  • The “FireEye” service created in the SSLO config creates 8 VIPs:
  • “-FireEye-t-4” is the internal entry point to the FireEye for TCP IPv4 traffic. This is where decrypted traffic leaves the F5 to the FireEye.
  • “-FireEye-u-4”, “-FireEye-t-6”, and “-FireEye-u-6” are the same as above, except for UDP IPv4, TCP IPv6, and UDP IPv6, respectively.
  • The “-D-0” FireEye VIPs are inserted on the receiving side, traffic coming back from the FireEye to the F5.


The following pools are created:


  • The “-FireEye-4” and “-FireEye-6” pools point to the self-IP on the respective “-D-0” side, to be captured by the -D-0 VIPs. For an inline L2 service, traffic is routed across the BIG-IP via route domain separation, where the L2 service is physically placed in the middle.
  • The “-dlp” pool points to the ICAP server.
  • The “-ex-pool-4” pool points the defined IPv4 gateway.


The following iRules are added to the configuration:



  • FireEye-ilS is the “inline source” iRule, typically empty, that can manipulate traffic going to the FireEye. For example, inserting a header.
  • FireEye-ilD is the “inline destination” iRule, typically empty, that can manipulate traffic coming from the FireEye. For example, removing a header previously inserted.
  • FireEye-ilS-Auth and -ilD-Auth are similar to above but more specifically used to pass X-Authenticated-User identity information to the service, when SSLO (via APM) performs authentication.
  • dlp-ic is used to manipulate traffic on the way to the ICAP service, and in this case specifically disabled ICAP processing if the traffic is not HTTP.
  • policy-in_t is attached to the “-in-t-4” VIP and controls some of the traffic property collection (to be used in the policy).
  • policy-lib is a separate library iRule, called by -in_t for procedure-level functions.


The following policy is also created using the BIG-IP access and identity module (Accesss Policy Manager or APM).



Policy – This is a per-request policy, not a per-session policy. SSLO per-session policies are stateless and un-editable.

  • The policy is broken into a main policy and multiple macros
  • Categorization is the macro that performs initial URL category lookup (if needed)
  • filtering_bypass is the result of a same-named rule created in the SSLO security policy, and in this case calls the Categorization macro, then makes a decision to intercept or bypass based on a category match.
  • Pinners_Rule is a built-in macro that does the same as the above, except solely queries a custom “pinners” category for known pinner URLs.
  • ssloS_dlp is a service macro that controls traffic to the dlp service.
  • ssloS_FireEye is a service macro that controls traffic to the FireEye service.
  • ssloSC_my-service-chain is a service chain macro that controls flow through the set of services, as defined in the corresponding SSLO service chain.
Updated Jan 26, 2022
Version 2.0

Was this article helpful?


  • Hi,

    Any chance for some more in depth explanation what is purpose of each object created by SSLO? I once tried to figure it out but was not really sure if I decrypted correctly functions performed but all objects. Would be helpful in case some troubleshooting is necessary.

    If possible flow of traffic for one service could be described listing in order which objects are receiving traffic and where this traffic is send. Would appreciate it a lot!


  • Thanks for the feedback! This article has attracted much more attention than anticipated. I didn't plan on expanding on it but now I think that's a great idea.

  • Dear,


    Understanding each config element and espacially virtual servers is a must for me.

    It can help for troubleshooting, but most importantly, it helps when some iRule logic or custom configuration needs to be added at some point when it can't be done via the SSLO interface.

    I would also find it usefull to get some more insight on the gossip protocol and some errors corrections use cases with the iAppLX menu or event with restcurl commands. It helped me some time, but I also had to rebuild the whole config because I coudn't solve some issues.