Load Balance to an SSL Proxy Server

Since you're passing encrypted traffic through the BigIP it has no visibility into the type of traffic passing through it. I would lean toward using the logic in a CLIENT_ACCEPTED event, since your only real option here is to stick with layer 4 (assuming you don't want to terminate SSL on the BigIP).

 

 

-Matt

Thank you for the reply. No we are not terminating on the F5. Basically we want any SSL traffic (determined by port/s) to simply go to a different pool of proxies than the standard.

 

 

The HTTP rule I previously posted did look like it was working to a degree but I am not sure it is the best way to approach this.

 

Here is a client_accept rule that I tested.....unsuccessfully.

 

 

I used examples to build this rule yesterday so am not even sure if it has been pieced together correctly.

 

 

when CLIENT_ACCEPTED {

 

TCP::collect 20

 

}

 

when CLIENT_DATA {

 

if { [TCP::payload 20] contains "443" } {

 

pool WebWasher

 

log local0. "Rule for WebWasher HTTPS redirect"

 

}

 

TCP::release

 

}

 

 

 

After the standard 3way handshake on port 8080 to the proxy here is a dump of the next request sent on port 8080. This is where we want to make the decision as to which pool to go to based on the port number in the CONNECT request.

 

 

40.00010.72.1.4010.81.13.40HTTPCONNECT somesite.com:443 HTTP/1.0

 

 

 

 

 

Could anyone else please respond or offer suggestion? I always had good luck with this forum before. I am a little surprised with lack of response on a seemingly pretty simple issue for the experts.

 

 

Thanks,

 

 

Brad

Are you saying that the only indication that the traffic is 443 is in the URI? So you can't create a virtual server on 443 that just uses the other pool?

 

 

If that's the case then there's really no way to do this without terminating SSL on the LTM, since you're trying to look into encrypted data with TCP::payload to make the determination.

 

 

Denny

Hi Denny. thanks for the reply.

 

I want to be able to look in to any traffic coming in on tcp port 8080 destined for the proxy servers and ultimately the Internet. If I see the connect string within that packet for any port that is potentially ssl (as determined by us) I want that traffic to be sent to a different pool.

 

I have 2 sets of proxies for Internet Access but only one VIP. All unencrypted traffic can go through the one set of proxies but any potential SSL traffic should go to the other set specifically deployed to inspect that traffic.

 

I want the rule on the port 8080 VIP to look for connect strings that use ports like 443, 9443, 6443 etc.

 

I hope I am being clear here. Please let me know if not and I will try to explain this better.

 

Right now if I look at a capture of port 8080 traffic I can see within those packets connect requests going to host:port. I want to make a decision based on those request port numbers. Would it be helpful to upload a cap of what I am looking at?

 

Thanks,

 

Brad

Hi Brad,

Yes a cap might be helpful, but I think I see what you are saying now...if you are seeing the port info in clear text then you ought to be able to make a decision on that.

You could add some more logging to your current rule to see what it's capturing and verify that we are indeed seeing the 443 string within that 20 bytes:

 
 when CLIENT_ACCEPTED { 
    TCP::collect 20 
 } 
 when CLIENT_DATA { 
  log local0. "TCP payload is [TCP::payload 20]" 
    if { [TCP::payload 20] contains "443" } { 
       pool WebWasher 
       log local0. "Rule for WebWasher HTTPS redirect" 
 } 
 TCP::release 
 }  
  
 

Denny