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.