6.3. Deploying SSL Orchestrator in Front of an Explicit Proxy

6.3.1. What it is

While you can insert a proxy device inside the SSL Orchestrator service chain, it may sometimes be useful to deploy SSL Orchestrator in front of an explicit proxy. For example,

  • An explicit proxy is defined as the organization’s outbound gateway and that function cannot move to the SSL Orchestrator.


  • Full challenge-response authentication is required at the existing explicit proxy. Inside the service chain, SSL Orchestrator must perform the user authentication with an APM access profile and pass the authenticated user information in-band to the proxy (via HTTP header). In this pass-through proxy mode, the user authentication can pass directly to the upstream proxy server.


    ../../_images/image921.png

    Figure 92: SSL Orchestrator Egress to Explicit Proxy

In this case, there are two modes that make the above possible:

  • Proxy Chaining Mode – where the client communicates with an SSL Orchestrator explicit proxy, which then communicates with an upstream explicit proxy (as the client).


  • Proxy Pass-Through Mode – where the client communicates directly with the upstream proxy through an SSL Orchestrator layer 3 transparent proxy (routed) topology.


6.3.2. Proxy Chaining Mode

Proxy chaining mode simply implies two explicit proxy servers end-to-end, where the client communicates with one of these, and that proxy communicates with the other (as the client). The user is otherwise unaware of the upstream explicit proxy. This configuration is reasonably straightforward, with minor changes to the topology.

  • Proxy chaining requires an explicit proxy topology mode.

  • Configure SSL settings as usual.

  • Configure security services and service chains as usual.

  • In the security policy, locate the Proxy Connect setting at the bottom of the page. Here you will define the upstream explicit proxy IP address and port, and optionally a static username and password if it supports Basic authentication. Enter as many IP addresses as needed here to load balance the upstream explicit proxy.

../../_images/image931.png

Figure 93: Proxy-Connect Settings

Figure X: proxy-connect-setting


6.3.3. Proxy Pass-Through Mode

Proxy pass-through mode implies that the user communicates with the upstream explicit proxy directly, passing through the SSL Orchestrator to get there. In this mode, the SSL Orchestrator topology is layer 3 transparent and acts as a routing point.

  • Proxy pass-through mode requires an outbound layer 3 topology mode.

  • Configure SSL settings as usual.

  • Configure security services and service chains as usual.

  • In the security policy, use the “HTTP Connect” category lookup condition instead of the SNI and All options, as traffic passing through the topology will be formatted by the client to speak to an upstream explicit proxy.

../../_images/image941.png

Figure 94: Proxy Passthrough Security Policy Example

  • On the Egress Settings page, you will likely not need to enable SNAT assuming the explicit proxy does not have a direct path back to the client subnet. You will also not likely require egress gateway settings if the upstream proxy is local. If the upstream proxy is not local, configure a system route.

In this scenario, the client will point to the upstream explicit proxy, which should not be local, and only accessible through the SSL Orchestrator route.


6.3.4. Proxy Pass-Through Mode (alternative option)

In the above you will notice that pass-through is simply that, and that the BIG-IP plays no part in load balancing an upstream explicit proxy. Normally that might be handled by other scaling processes, but there is an alternative option on the BIG-IP to do proxy pass-through and load balance the upstream proxy. The only significant limitation here is that it requires the topology to be taken out of strictness (permanently). To configure:

  • As before, a proxy pass-through configuration requires an outbound layer 3 topology mode.

  • Configure SSL settings as usual.

  • Configure security services and service chains as usual.

  • In the security policy, use the “HTTP Connect” category lookup condition instead of the SNI and All options, as traffic passing through the topology will be formatted by the client to speak to an upstream explicit proxy.

  • On the Interception Rules page, set a local destination IP address for the client to use for explicit proxy access.

  • On the Egress Settings page, enter the IP address of each upstream proxy.

  • Deploy and then disable strictness on the topology by clicking the lock icon to the far right of the topology object on the Topologies tab.

  • Navigate to Local Traffic -> Virtual Servers and click to edit the corresponding virtual server. This will be a virtual server ending with “-in-t-4” (or “-in-t-6”). Check to enable the Address Translation setting and click Update.

In this scenario, the client will point to the IP address and port configured for the topology, and the topology will load balance (and address translate) to the upstream explicit proxy.