on - edited on by
JRahm
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.
