Forward explicit SSL proxy server

There are a few moving parts.

1. Create the "tcp-forward" tunnel object
2. Create the DNS resolver object
3. Create the http-explicit profile that binds the tunnel and DNS resolver objects
4. Make sure you have a default outbound route. It may be helpful to jump onto the command line and nslookup/dig some remote site to make sure it resolves, and then cURL to it to make sure the F5 can actually get there
5. Create the proxy VIP - this is the IP::port that the client browser will be configured to talk to. A standard VIP, listening on specific internal IP and port (ex. 3128 or 8080), http-explicit profile, listening on client side VLAN, SNAT as required, address and port translation enabled
6. Create the "tunnel" VIP - this is the VIP that will maintain the HTTP CONNECT tunnel for SSL traffic. A standard VIP listening on 0.0.0.0, port 443 (or port 0 if you want to be able to handle HTTPS on any port), listening on the tunnel object created earlier, SNAT as required, address and port translation disabled

So the way it works, an HTTP proxy request hits the proxy VIP, is locally resolved, and is routed out the default gateway. An HTTPS proxy CONNECT request hits the proxy VIP, is locally resolved, and the proxy VIP establishes a TCP tunnel between the client and the tunnel VIP, and then responds to the client with a "200 Connection Established". Upon receipt of this message the client initiates its SSL handshake outbound, through the TCP tunnel, out the default gateway to the remote server. You don't technically have to process SSL at the tunnel VIP. If you do, that's called "SSL Forward Proxy", and you need the SSL Forward Proxy license for that. This license allows the F5 to re-issue the server cert to the client from a locally-installed (preferably subordinate) certificate authority. In this case, you'd

1. Install the CA certificate and private key
2. Create a client SSL profile that enables the SSL Forward Proxy option, binds the CA cert and key, and whatever other options you want there
3. Create a server SSL profile that enables the SSL Forward Proxy option, optionally enables the SSL Forward Proxy Bypass option, optionally sets the Server Authentication - Server Certificate option to require, and provides a certificate bundle for the Trusted Certificate Authorities option (if Server Certificate is set to require). The ca-bundle certificate bundle is comprised of the Mozilla CA trust stack and is updated often. You may optionally want to modify the Ciphers option to: "DEFAULT:ECDHE_ECDSA" if you're running at least 11.6HF5, and it would be wise to also set the Secure Renegotiation option to Request or Require as there are still many servers on the Internet that don't support RFC5746 Secure Renegotiation.
4. Bind the client and server SSL profiles to the tunnel VIP

There's no difference in the license itself, but I do not believe the Lab VE comes with SSL Forward Proxy. You'll see it on the License page listed as SSL, Forward Proxy. I egree though that there are a few documents that don't mention the separate license.

I know that you can license it on the Lab VE, but I don't think the $98 Lab VE comes with by default.

If you attempt to use SSL Forward Proxy features without the license, it will surely fail.

At a minimum, if you remove the TCP ingress VIP and just leave the proxy VIP, you should be able to do outbound HTTP (HTTPS should fail with a 503). If that works, create the ingress TCP VIP with the following minimum properties (leave everything else at default):

• Type: Standard
• Destination Address/Mask: 0.0.0.0/0
• Service Port: 443
• VLAN and Tunnel Traffic: Enabled on the tunnel VLAN
• Source Address Translation: SNAT if you need it for outbound traffic
• Address and port translation: unchecked

In this case you're just creating a tunnel to allow HTTPS traffic to pass, without attempting to decrypt. Again, without the license it will definitely fail if you apply SSL profiles.

Have followed the documentation and have the same result - no traffic hits the SSL-Forward-Proxy VIP.

Andrew, assuming you're also doing explicit proxy, you should have two ingress VIPs: the proxy vip listening on some IP and proxy port, and a wildcard TCP VIP listening on 0.0.0.0/0 and port 443 (or any port), that is bound to the proxy tunnel object that you created and also applied to the http-explicit proxy (which is applied to the proxy VIP).

Which VIP are you observing?

You technically just need 11.4 and above to make this work. Your ingress TCP wildcard VIP should have absolutely nothing applied (assuming you're not decrypting and re-encrypting):

• Type: Standard
• Destination address/Mask: 0.0.0.0/0
• Service Port: 443 (or * All ports)
• Protocol: TCP
• VLAN and Tunnel Traffic: enabled on the same tunnel that you used in the http-explicit profile
• Source Address Translation: SNAT as required
• Address Translation: unchecked
• Port Translation: unchecked
• Default Pool: your gateway pool

Notice that there's no HTTP or SSL profiles attached to this VIP.

Okay, so just a crazy set of questions here, but

1. Do you have an HTTP profile applied to the TCP wildcard VIP? You shouldn't.

    

2. Does the destination address include the mask (ex. 0.0.0.0/0), versus just 0.0.0.0? If not, it should.

    

Sorry for interrupting you. From my point of view, you might hit ID597099.

597099SSL forward proxy appears to be unable to handle an SSL handshake inside an explicit proxy 'CONNECT' request. This appears to be the case if the explicit proxy trails the SSL Forward Proxy, or is within the inspection zone. There is no workaround.

https://support.f5.com/kb/en-us/products/ssl-orchestrator/releasenotes/product/relnote-ssl-orchestrator-12-1-0.html

597099SSL forward proxy appears to be unable to handle an SSL handshake inside an explicit proxy 'CONNECT' request. This appears to be the case if the explicit proxy trails the SSL Forward Proxy, or is within the inspection zone. There is no workaround.

I don't believe that case applies here. This is when the F5 is in transparent proxy mode, there's an explicit proxy inside the inspection zone, and the client is attempting to communicate via explicit proxy requests to the "internal" explicit proxy, through the F5 transparent proxy. If you apply SSL Forward Proxy at this F5 ingress point, SSL Forward Proxy is currently not able to decrypt (and re-encrypt) the SSL session created inside the proxy tunnel between the client and the internal proxy.

In this thread, the F5 is an explicit proxy and Marvin and Andrew are just doing SSL Forward Proxy, and at this point not even trying to decrypt the outbound SSL traffic. In the F5 explicit forward proxy scenario, the proxy tunnel is actually established between the client and the ingress TCP wildcard VIP, through the proxy VIP, and the ingress wildcard VIP is the one providing SSL Forward Proxy decrypt/re-encrypt services.

Just to re-iterate, that bug is only relevant when there's an explicit proxy inside the inspection zone, the F5 is in transparent proxy mode, the client is trying to talk directly to the internal explicit proxy, and the F5 is trying to decrypt the SSL session between the client and the internal explicit proxy. You absolutely CAN work around that scenario by putting the ingress F5 in explicit mode (with some additional iRule logic to reformat decrypted HTTP requests to talk to the internal explicit proxy), or by putting the internal proxy in transparent mode.

Hi Kevin,

What's the trick to forwarding the HTTP traffic out the back of the Explicit VIP? The SSL traffic traverses the tcp-forward tunnel to the wildcard VS where it can be managed. How would I forward everything else (in particular, HTTP) where I want (e.g. to another VS or gateway pool)?

I've tried using the HTTP_PROXY_REQUEST event and proxy disable to send it various places. I can successfully send it to another VS however what I really want to do is send it through a security device. The SSL Intercept iApp 1.0 does this for HTTPS via an ingress pool, however I can't get this working for HTTP?

Without a fancy iRule solution, I guess creating routes is the only way to get it where I want.

Any tips?