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.Tear Down This Wall! (Or at least punch a hole in it)
Back in 1987, President Reagan stood at Brandenburg Gate in Berlin and issued these iconic words: "Mr. Gorbachev, tear down this wall!" Sure, there was a path from east to west during the cold war at Checkpoint Charlie, but the existence of said path and the ability to traverse that path were not one in the same, at least among those valuing their life. At this point you might be asking what the heck this has to do with BIG-IP? Well, let me tell you! One of the more common misconceptions about BIG-IP concerns routing. A route (n) is (as defined in the Google) "a way or course taken in getting from a starting point to a destination." So far so good. Routes are easy to add and easy to follow. Static routes anyway. I believe the confusion lies in the fact that the BIG-IP is a default deny box. That means, like Checkpoint Charlie, just because there is a path doesn't mean that traffic is going to be allowed on that path. This is not an "If you build it, they will come" situation, as much as it pains me to break it to Ray Kinsella there to the right. In order for traffic to flow through the BIG-IP, it has to be explicitly allowed and this is done with virtual servers. Virtual servers are the tearing down (or punching holes) of the BIG-IP default deny wall. Whether you need to route all protocols for specific networks, or deliver a variety of applications, you can configure specific or wildcard servers of many different types, meticulous details of which can be found in Solution 14163. For a specific example, consider this question raised in Q&A yesterday. The original poster wanted to be able to route some traffic between vlans with no translation, while allowing translation on other traffic. Again, all this work is done in the forwarding configuration, not the routing configuration. Assumptions: outside vlan: 172.16.100.0/24 (nat outbound traffic to this subnet from inside vlans) inside vlans: 192.168.1.0/24, 192.168.2.0/24 (do not nat traffic between these or to the remote servers) ipsec link vlan: 192.168.99.0/24 remote servers: 192.168.100.0/24 (do not nat internal server traffic to remote servers) The diagram (remote servers on other side of a ipsec tunnel): Alexander came up with a working configuration after seeding the discussion with some of the above concepts, go check it out!
