Requests from BlueCoat SG Proxy Return 404.4

What does tcpdump say?

Is there a virtual server configured to accept those connections on the F5, and forward them to the final web server?

The site is fully setup on the F5. A virtual server is configured mapped to a pool forwarding requests to back-end webservers in LTM. The site is also setup in GTM. We don't have tcpdump installed.

Thanks.

Hi, If everything is configured on the F5 and the traffic actually reaches your web servers, then the most likely thing is that the domain name (the host header) when the requests get to your web servers is not recognised by your web servers. This seems to me like what the message "no handler configured" means. I'm more familiar with Apache myself, but this seems like the explanation.

Thanks for looking. Here is more info on the issue. We confirmed that non-encrypted traffic (http) from the BlueCoat proxy receives 200 status from wen servers. The same requests via https are getting 404.4

Could be that the Blue Coat isn't permitting the F5's IP address to retrieve content from it. Has the client investigated the Blue Coat as a possible culprit? I've seen Blue Coats block traffic from newly configured load balanced content through LTMs before. Ran into the issue a couple weeks ago actually.

The issue is still present, but now we know exactly what's happening when the client sends requests. We analyzed packets of good (200) and bad (404) responses. Bad requests are bad because the GET packets contain the domain name pre-pended to the URI. Examples:

GOOD: 1 8 1408563642.5949 (0.0006) C>SV3.1(480) application_data --------------------------------------------------------------- GET /myURI?myQueryString HTTP/1.1 Host: mySite.com Connection: keep-alive

BAD: 2 8 1408641901.6124 (0.0011) C>SV3.1(400) application_data --------------------------------------------------------------- GET https://mySite.com/myURI?myQueryString HTTP/1.1 Host: mySite.com WL-Proxy-SSL: true

My guess is this is a configuration issue on the client's proxy and I will ask them to verify that. But could someone please help me come up with an iRule that would remove the "https://mySite.com" portion from the request the client is sending?

can you try something like this?

 config

root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
    destination 172.28.24.10:443
    ip-protocol tcp
    mask 255.255.255.255
    pool foo
    profiles {
        clientssl {
            context clientside
        }
        http { }
        tcp { }
    }
    rules {
        qux
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 70
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool foo
ltm pool foo {
    members {
        200.200.200.101:80 {
            address 200.200.200.101
        }
    }
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
ltm rule qux {
    when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "https://mySite.com/" } {
    HTTP::uri [string map {https://mySite.com/ /} [HTTP::uri]]
  }
}
}

 test

1 10 1408672423.5666 (0.0039)  C>SV3.1(94)  application_data
    ---------------------------------------------------------------
    GET https://mySite.com/myURI?myQueryString HTTP/1.1
    Host: mysite.com


    ---------------------------------------------------------------
New TCP connection 2: 200.200.200.14(40399) <-> 200.200.200.101(80)
1408672423.5814 (0.0139)  C>S
---------------------------------------------------------------
GET /myURI?myQueryString HTTP/1.1
Host: mysite.com

---------------------------------------------------------------

Hi Nitass, it worked great! Appreciate your help again with iRules. I'll follow up with the client and see how the testing will go.