Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner

Forward proxy with SSL passthrough - SWG license required?

autopoiesis
Altostratus
Altostratus

Hi,

At one site with a single v15 VE I need to proxy outbound traffic, but without SSL inspection.  Most docs relating to SSL passthrough assume that targets are internal and pooled but this is not my scenario: internal clients must connect to numerous (but specified) external URLs outside my control, and whose IPs are constantly changing.

This similar query states solved via iApp but does not specify which one, or much detail on the final config.  Regarding the license aspect, other proxy-related posts refer to the need for SWG license (which I don't have) - would I need this?

The documentation for this use-case is unclear; any comments/tips gratefully received!

Cheers,

auto

5 REPLIES 5

Mike757
MVP
MVP

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-pr...

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

autopoiesis
Altostratus
Altostratus

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

Hmm, no joy.

I get CONNECT entries logged on the explicit proxy VS, but nothing at all on the wildcard (the CONNECTs are followed by http-keep-alives and their ACKs from :8080, until timeout).  Same behaviour regardless of whether the target URL is http, or https.

It's as if nothing is being passed from the explicit proxy through to the wildcard proxy.  I've rechecked that the config and don't believe I missed anything.  But TBH I don't understand quite how the 'connection' from explicit VS ->wildcard VS is supposed to work in the first place.

Any pointers/tips welcome.

MyHomeNWLab
Altostratus
Altostratus

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.

There is also a way to deploy with iApps templates.
F5 provides a iApps template for secure_web_gateway. However, it is now deprecation.
I think SSLO is a more enhanced version of this iApps Template.

  [Download Site]
  https://downloads.f5.com/
  Menu: iApp Templates > iApp-Templates
  Filiname: iapps-1.0.0.562.0.zip
  iApps template: f5.secure_web_gateway.v1.1.0rc4.tmpl

Removing "SWG" from "Required BIG-IP Modules" will work without SWG module.
I have confirmed that it works with BIG-IP VE Lab & Version 15.1.1.

[From iApps README Deprecation.txt]
> This zip file contains all of the downloadable iApp template files officially supported by F5 Networks.
>
> With this release, a subset of iApp templates are being deprecated as of 12/05/19.
> The planned EoSD/EoTS/EoL date for these iApp templates is 12/31/20.