Forum Discussion

BaltoStar_12467's avatar
Dec 26, 2013

BIG-IP : redirect loop : debugging techniques

BIG-IP 11.4.0 Build 2384.0 Final

In my hosts file I point

www.mydomain.com
to my web-server IP, and in my client-browser I submit the request

http://www.mydomain.com/natural-language-url-1

and the page is returned as expected..

In BIG-IP , I have configured a single virtual-server

vip-01
with a single iRule
irule-01
:

when HTTP_REQUEST {
  log local0. "HTTP_REQUEST received by irule-01"
  log local0. "host = [HTTP::host]"
  log local0. "uri = [HTTP::uri]"
  switch -glob [string tolower [HTTP::host]] {
    "www.mydomain.com" {
      switch -glob [string tolower [HTTP::uri]] {
        "/api/*" {
          pool service-pool-01
        }
        default {
          log local0. "matched default pool"       
          pool default-pool-01
        }
      }
    }
  }
}

Now, in my hosts file I point

www.mydomain.com
to
vip-01
, and in my client-browser I submit the request

http://www.mydomain.com/natural-language-url-1

and the client-browser reports an infinite-redirect error

"This webpage has a redirect loop"

BIG-IP > System > Logs > Local Traffic

Rule /Common/irule-01 : HTTP_REQUEST received by irule-01`
Rule /Common/irule-01 : host = www.mydomain.com
Rule /Common/irule-01 : uri = /natural-language-url-1
Rule /Common/irule-01 : matched default pool

... repeat 10 times ...

Fiddler shows that 21 302-redirects have occurred :

Result          302
Protocol        HTTP
Host            www.mydomain.com
URL             /natural-language-url-1
Body            185
Caching         private
Content-Type    text/html; charset=utf-8
Process         chrome:7516
Comments
Custom  

NOTE 1 : on vip-01, Source Address Translation = Auto-Map

NOTE 2 : I have complete control over the web-server ( remote access with ability to modify configuration, run diagnostics, perform local tests, etc. )

NOTE 3 : The web-server expects the request to include the domain. Sending a request with host = {web-server-host-name} , or host = {web-server-ip} will throw an error because IIS will be unable to locate the virtual app.

What are some debugging techniques I can deploy to further diagnose the underlying cause of the redirect loop ?

28 Replies

  • From the command line, type:

    ifconfig    
    

    This will show you all of the interfaces on the system. If for example you've named the internal VLAN "internal", then you can actually use this VLAN name in tcpdump.

    tcpdump -lnni internal -Xs0    
    

    If you wanted to show traffic from all interfaces, you can use 0.0

    tcpdump -lnni 0.0 -Xs0
    

    As for additional filters, assuming you have other traffic on the internal VLAN that you want to not see, you can add filters to the tcpdump to limit what you capture. So for example, if the web server is listening on port 80 and its IP address is 10.10.10.1, a tcpdump with additional filtering might look like this:

    tcpdump -lnni internal -Xs0 host 10.10.10.1 and port 80    
    

    The -Xs0 option will dump the layer 7 payload to the screen, so you'll be able to see a 302 response if it is in fact coming from the web server.

  • John_Alam_45640's avatar
    John_Alam_45640
    Historic F5 Account

    Looking at the response from curl command, the server header says "Microsoft iis". That pretty much guarantees that it is the server that is sending the 302 redirect.

     

    If the bigip sent a 302, the server header would have been "BIGIP". unless it is configured to masquerade as an iis server which I don't think you did.

     

  • Good catch John. So BaltoStar you should definitely see the 302 coming from the web server, which now of course begs the question, why? Is there ANYTHING configured in IIS or the application itself that could do this? Specifically, what conditions might the web server or asp.net be configured to issue a redirect? Given that the layer 7 HTTP requests are virtually identical, can it not like the source address? Do you see any differences in the HTTP request on the client side of the F5 and on the server side, as in the F5 may be altering the request along the way? You'd see this in your internal tcpdump. Is there otherwise anything different between a direct request and the proxied request other than the source address? If you were to stand up a simple generic web page in IIS, can you get it through the F5?