Forward proxy with SSL passthrough - SWG license required?

Hi auto,

If you want to use explicit proxy in the internal clients, you can use this "recipe":

https://community.f5.com/t5/technical-articles/configure-the-f5-big-ip-as-an-explicit-forward-web-proxy-using/ta-p/286647

I'm not sure this can be adapted to transparent proxy. I would imagine you don't need the DNS resolver in that case, but the HTTP profile might not make sense either.

I'm almost sure I've done something similar in the past with an iApp, but maybe I had the SWG module provisioned. I really can't recall.

Hope it helps!

/Mike

Many thanks for the link, Mike.  This looks pretty similar to the description of the other, iApp-based solution; I'll test and give some feedback.

All the best,

auto

First, the underlying function of the L3 Explicit Forward Proxy works with LTM.

The following setup is easy to understand and very helpful.

  Use F5 LTM as HTTP Proxy - DevCentral
  https://community.f5.com/t5/codeshare/use-f5-ltm-as-http-proxy/ta-p/287908

If LTM only, SSL decryption is controlled by iRules as needed.
Control by iRules is complicated, and from my own experience, I would never recommend it.

  SSL::forward_proxy
  https://clouddocs.f5.com/api/irules/SSL__forward_proxy.html
  > SSL::forward_proxy policy <[bypass] | [intercept]>

If you have APM, you can control SSL decryption from VPE (Visual Policy Editor).

  [How to set up]
   * "SSL Forward Proxy Bypass" in the SSL Client & Server Profile must be Enabled.
   * Apply the Item of "SSL Bypass Set" to the communication subject to SSL decryption in Per-Session Policy.

Forward Proxy is often deployed for security purposes, so APM is usually used.

If you want to use dynamic database for URL filtering, SWG is required.
If you are using a full allowed list (manual registration), you do not need SWG.

Another option is to set up from SSLO (SSL Orchestrator).
SSLO primarily provides setup guides.
The SSLO module runs in iApps LX and handles LTM and APM functions from iApps LX.
Therefore, SSLO behaves in a very tricky way.

For example, SSLO synchronizes configuration from iApps LX by REST API.
This implementation is separate from ConfigSync to minimize service down.
In the worst case, this implementation can lead to synchronization failure by REST API and configuration collapse.
In my experience, the Version 15 series was prone to configuration collapse.
Since Version 16, the behavior has been improved.
For this reason, I personally would not recommend SSLO easily.

To reduce the risk of deployment in a production environment, it is recommended to perform a PoC in the BIG-IP VE Lab.
BIG-IP VE Lab can use LTM, APM, and SSLO modules.
Although SWG is not available, it should still provide the information necessary to consider deployment.
If you use SSLO, it is recommended to deploy BIG-IP VE Lab in HA pairs to confirm the aforementioned behavior.