Forum Discussion

Marvin_129795's avatar
Marvin_129795
Icon for Nimbostratus rankNimbostratus
Sep 02, 2016

Forward explicit SSL proxy server

Dear all,

 

Trying to figure out why HTTPS traffic is not passing the forward proxy. I followed the following article, configured the HTTP and SSL profiles and the two virtual servers accepting HTTP and HTTPS traffic. The only thing that we dont use is the APM part.

 

Result is that when using the explicit IP address configured in HTTP virtual server and the local browser client is that it works just fine when accessing HTTP websites. When I try to access a website with HTTPS using the explicit IP address configured in my browser I can see an HTTP CONNECT and the virtual server replies with service unavailable HTTP 503. This happens with all HTTPS sites. If I change the proxy setting in the browser the HTTPS (port 443) to request is simply being reset.

 

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-12-0-0/7.html

 

Does anyone has experience in deploying Big IP LTM as a explicit forward proxy using HTTP and clientSSL profiles only without the use of Irules?

 

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

       

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

     

  • 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?

     

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

     

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

     

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

     

  • 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