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.
