Forum Discussion

xunil321_122934's avatar
xunil321_122934
Icon for Nimbostratus rankNimbostratus
Aug 03, 2016

HTTP Explicit Proxy and http requests

Dear all,

 

we have used this iApp (https://devcentral.f5.com/codeshare/apm-explicit-proxy)

 

to install an explicit proxy under 11.5.1 HF7 where the client's browser is pointing

 

to this one. In the next step we have built a VS listening to the tunnel that the explicit

 

proxy has established. By applying an iRule or an APM profile for this VS we are

 

able to control the client's web access ie only selected hosts/uri are allowed to visit.

 

As long as we are calling sites with httpS://..... irule/APM profile are triggered

 

BUT using HTTP://.... no profile of the VS is triggered, although we disabled the VS

 

HTTP web access is granted. Very, very strange.

 

Why?

 

Many thanks for any explanation!

 

Rainer

 

  • Ah, so the difference here is in how explicit proxy handles http vs. https. Https traffic is in fact sent into the tunnel to be picked up by a wildcard virtual server as you discovered, however http traffic is sent directly to the end web server requested using routing specified under network->routes. As far as forcing non-encrypted http traffic to hit that virtual server requires some irule manipulation to accomplish that. A simpler strategy then trying to "virtual" the connection over to wildcard vs is in the HTTP_PROXY_REQUEST method on the explicit proxy VS you could run some of that same logic and block connections based on uri and/or ip right there.

     

5 Replies

  • JamesSevedge_23's avatar
    JamesSevedge_23
    Historic F5 Account

    Ah, so the difference here is in how explicit proxy handles http vs. https. Https traffic is in fact sent into the tunnel to be picked up by a wildcard virtual server as you discovered, however http traffic is sent directly to the end web server requested using routing specified under network->routes. As far as forcing non-encrypted http traffic to hit that virtual server requires some irule manipulation to accomplish that. A simpler strategy then trying to "virtual" the connection over to wildcard vs is in the HTTP_PROXY_REQUEST method on the explicit proxy VS you could run some of that same logic and block connections based on uri and/or ip right there.

     

    • JamesSevedge_23's avatar
      JamesSevedge_23
      Historic F5 Account

      Sample iRule Basic Logic

      when CLIENT_ACCEPTED {
      
      block by IP
      
      } ; CLIENT_ACCEPTED
      
      when HTTP_PROXY_REQUEST {
       if {[HTTP::method] eq "CONNECT"} {
         HTTP Profile will forward via tunnel to transparent proxy
        return
       }
      
      otherwise you know it is non-tls and as such could use HTTP:: commands to parse request and decide on allow/disallow.
      
      } ; HTTP_PROXY_REQUEST
      
    • xunil321_122934's avatar
      xunil321_122934
      Icon for Nimbostratus rankNimbostratus

      James,

       

      things become clearer and clearer. Many thanks, but WHY does the proxy

       

      handles the http/ https traffic in a different way? Any idea behind this?

       

    • JamesSevedge_23's avatar
      JamesSevedge_23
      Historic F5 Account

      This was the way the explicit proxy was designed, I cannot go into specifics as I am not aware of complete reasoning but because of the way TLS vs. non-TLS is handled using the CONNECT verb from the client side it was determined for various reasons at the time that any manipulation by HTTP traffic could be handled on the explicit VS directly as I mentioned above and then passed using routing to the end web server directly as opposed to going through another layered VS as is done for HTTPS to improve performance, etc... There is discussions about improving the options in the explicit proxy profile to potentially allow more options to this behavior in the future but as of now this is how it is designed. To allow for adding of disallowed ipuri's in a single place each of the irules (explicit+wildcard VS) could make calls to a datagroup(s) that would compare current connection ip/uri to disallowed ip/uri's in the datagroup(s) so that as an admin you would just need to update the datagroup(s) and both irules on different VS's would block those new ip/uri's dynamically based on that. Hopefully this helps!