on 26-Dec-2018 03:00
Based on the number of inquiries around F5's SSL Orchestrator, I wanted to take a few moments to provide a how-to guide on deploying SSLO with an explicit forward web proxy in the inspection zone. There are actually many ways in which we could deploy SSLO with forward web proxies, though the two most common use cases I have run into are using F5's SWG as a service on the same box if you currently subscribe to F5's SWG and using an existing forward proxy like Bluecoat SG inside the inspection zone.
If you are new to the industry and looking for a forward web proxy solution, it is important to understand that many of these appliances are not designed to handle large volumes of cryptographic traffic. Today, I can name several customers off the top of my head who are experiencing this problem which prompts their administrators to bypass the forward proxy solution altogether. F5 is unique in the industry as it is a full proxy designed to support a large number of SSL transactions. In fact, not only does F5 continue to improve hardware performance but they also continue to improve software performance as the SSLO product continues to mature. With that, let's begin discussing the use case at hand.
For this particular how-to guide, I will be using an F5 BIG-IP licensed with SSLO, URLDB, LTM and APM running on BIG-IP version 14.1. In our inspection zone, we will be pointing to an explicit WSA HTTP proxy. If you are looking for a guide on using SWG and how to restrict access to different URL categories based on Active Directory security group, see Configuring the F5 BIG-IP as an Explicit Forward Web Proxy Using Secure Web Gateway (SWG) on DevCentral. This guide was written to expose you to F5's SSLO 5.0 as well as a glimpse into the breadth and depth of its capabilities. Let's get to it!
Certificate Key Chain
CA Certificate Key Chain
Before moving to the next step, take a moment to scroll through the list of different services. It is likely you already have one of these other products in your data center, and F5 is making it that much easier for you to integrate them. This list will continue to grow as the product grows.
In this section, we are defining the IP address of the WSA HTTP Proxy
Note: In this use case we are not performing authentication; though if authentication is required, this would be offloaded to the BIG-IP.
Note: This is where we will be defining what content to not decrypt but rather bypass the proxy process due to the traffic content. Examples of this would be financial or health-related websites. This is where the URLDB is utilized in order to determine the URL category.
Note: While many more objects are created during the deployment of SSL Orchestrator, reviewing each item is outside the scope of this document.
Here you can identify things such as URL Categories, Decryption Status, Service Paths taken and much more. Once this is complete, you have successfully deployed SSL Orchestrator supporting an explicit forward web proxy in your inspection zone. This will allow F5 to perform all of the heavy SSL decryption and re-encryption while using the security tools as they were designed to be used. Until next time!
Great article. What I can't figure out is how to configure routing on external proxy.
My assumption is that:
Based on that what default route should be set on EP? Should in point to 198.19.96.245?
If so I have to be missing something as all the time traffic is just reset by ssloS_explicit-D-0-t-4 that as far as I understand should process it and send to the Internet - or I am completely missing the point here?
Hey Piotr, great questions. Let me re-deploy and provide more specific details with screenshots around routing.
Would be great. Maybe I messed my config around but maybe as well I just don't understand how external Proxy should be configured related to routing. Results I've got are that traffic is reaching my external proxy (in this case another BIG-IP with Explicit proxy configured) form SSLO box but is never delivered to target site 😞
When configuring the security policy and bypassing Financial and Health traffic, there should probably be a logical AND between the two statements: SSL check AND category lookup. Would it not otherwise bypass all SSL traffic?