Forward explicit SSL proxy server

  I updated the link.

You can find here working simple configuration of http proxy without swg (tested on version 13.1)

 

Hi all,

I'm having exactly the same problem: HTTP works and HTTPS not work with an 503 Service Unavailable. The only difference is that i made the implementation through an SWG iApp. Any ideas ?

Hi Andrew, i configure the same thing like what you do. i can open http and https web (youtbe) the problem when open the facebok or download large file via browser. seems like only open 1 connection, it very slow to download or load the facebook web face this problem before?

i run VE, with 8GB RAM and 4 core cpu. i dont think throughput issue.

thanks in advance.

Dear all use my config but only change the virtual server port from 443 to all and then it works fine, problem solved!

There are at least three ways to get HTTP traffic to go through your inspection devices.

1. Use the new SSL Intercept 1.5 iApp, which supports this use case and much more.

2. If you're doing this across two boxes, set the internal box's default route to the internal self-IP of the second box. Or if on a single box, create a route domain that separates a "dmv internal" VLAN from a "dmv external" VLAN, and then make the box's default route the dmv external VLAN self-IP. So you'd have a client side VLAN, Internet side VLAN, and two internal VLANs through which your decrypted traffic would flow from ingress to egress.

3. Use an iRule to force traffic through the inspection zone. In the iRule attached to the http-explicit VIP, the HTTP_REQUEST event will only fire for HTTP traffic. HTTPS traffic is sent directly to the wildcard TCP VIP. The only caveat to this is that by the time the HTTP_REQUEST event fires, the outgoing traffic hasn't been IP translated yet. In other words, the source address and port are still the http-explicit VIP's address and port. Here's what the iRule might look like:

   when RULE_INIT {
        User-Defined: optional internal DNS cache (in seconds)
       set static::DNSCACHE_TIME 20
   
        User-Defined: path for the decrypted traffic. This can be a wildcard VIP on the other side of a route domain and VLAN for inline layer 2 devices, or the inbound IP address of an inline layer 3 device. In any case it's defined as a pool so that you can effectively load balance across multiple security devices
       set static::L2_SERVICE_POOL "my_service_pool"
   }
   when CLIENT_ACCEPTED {
        Check for service availability. If services are down, bypass SSL inspection and just exit
        The default path for HTTP explicit traffic, via http-explicit, is the system default route. If the inline security devices are available, you're going to trigger commands in the HTTP_REQUEST event. Otherwise let the traffic follow its native path to the system default gateway
       if { [active_members $static::L2_SERVICE_POOL] > 0 } {
            At least one security service is available
           set PROXY_ON 1
       } else {
            No security services are available - exit via system default route without inspection
           set PROXY_ON 0
            Enable outbound SNAT from here (as required)
           snat automap
       }
   }
   when HTTP_REQUEST {
        This event is only triggered for HTTP requests
        HTTPS (CONNECT) requests are sent to the ingress TCP VIP by default
       if { $PROXY_ON } {
            Pick an active service pool member. We're routing here. Normally you'd just turn off address translation in the VIP, but since you actually need this enabled for HTTPS traffic, you're going to use a combination of 'node' and 'nexthop' to effectively creating a routed path. First pick an inline security service pool member.
           pool $static::L2_SERVICE_POOL
           set next_service [lindex [LB::select] 3]
   
            The incoming destination address is local, so resolve the host and re-inject the true 
            destination address via node command, and account for non-standard ports
           set proto 1
           catch {
               if { [HTTP::host] contains ":" } {
                   set host [lindex [split [HTTP::host] ":"] 0]
                   set port [lindex [split [HTTP::host] ":"] 1]
               } else {
                   set host [HTTP::host]
                   set port 80
               }
               set this_host [lindex [RESOLV::lookup -a ${host}] 0]
   
                Optionally create a local table to cache DNS responses so that you're not always doing two DNS queries per request
               if { [table lookup -subtable DNSCACHE ${host}] ne "" } {
                   set this_host [table lookup -subtable DNSCACHE ${host}]
               } else {
                   set this_host [lindex [RESOLV::lookup -a ${host}] 0]
                   table set -subtable DNSCACHE ${host} ${this_host} $static::DNSCACHE_TIME
               }                    
   
                Then set the traffic path in the direction of the resolved node
               node ${this_host} ${port}
           }
       }
   }
   when LB_SELECTED {
        Only do this for HTTP traffic. The true destination address was re-inserted via node 
        command above, so set the nexthop route to the target VLAN self-IP. So if this is HTTP traffic and the inline security services are available, you're going to instruct the outgoing traffic to go through the selected inline security service, thus forcing a routed path
       if { [info exists proto] } {
           LB::reselect nexthop ${next_service}
       }
   }
   

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?

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?

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.

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