Error sending traffic to the pool

Hi Roman,

You could do something like this:

when HTTP_REQUEST {
switch -glob [string tolower [HTTP::uri]] {
"/start*" -
"/landing*" -
"/login*" { pool login_pool }
default { pool utility_pool }
}
}

Is there a way to send traffic to a specific POOL or VIP with the uri different from what the user has typed?

Yes. Here are two that can be utilized to manipulate the URI that is being sent to the server while masking the change to the Client:

HTTP::uri - http://devcentral.f5.com/wiki/iRules.HTTP__uri.ashx

URI::path - http://devcentral.f5.com/wiki/iRules.URI__path.ashx

Hope this helps.

e.g.

[root@iris:Active] config  b virtual bar list
virtual bar {
   snat automap
   destination 172.28.17.33:http
   ip protocol tcp
   rules myrule
   profiles {
      http {}
      tcp {}
   }
}

[root@iris:Active] config  b rule myrule list
rule myrule {
   when HTTP_REQUEST {
        switch [string tolower [HTTP::uri]] {
                "/" -
                "/start" -
                "/landing" -
                "/login" {
                        HTTP::uri "/"
                        pool login_pool
                }
                default { pool utility_pool }
        }
}
}

[root@iris:Active] config  b pool login_pool list
pool login_pool {
   members 10.10.70.110:http {}
}

[root@iris:Active] config  b pool utility_pool list
pool utility_pool {
   members 10.10.70.120:http {}
}

1) curl -I http://172.28.17.33/

New TCP connection 1: 172.28.16.50(60036) <-> 172.28.17.33(80)
1318315141.9987 (0.0012)  C>S
---------------------------------------------------------------
HEAD / HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

New TCP connection 2: 10.10.72.30(60036) <-> 10.10.70.110(80)
1318315141.9992 (0.0003)  C>S
---------------------------------------------------------------
HEAD / HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

2) curl -I http://172.28.17.33/start

New TCP connection 3: 172.28.16.50(60055) <-> 172.28.17.33(80)
1318315185.4511 (0.0005)  C>S
---------------------------------------------------------------
HEAD /start HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

New TCP connection 4: 10.10.72.30(60055) <-> 10.10.70.110(80)
1318315185.4515 (0.0003)  C>S
---------------------------------------------------------------
HEAD / HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

3) curl -I http://172.28.17.33/landing

New TCP connection 5: 172.28.16.50(60068) <-> 172.28.17.33(80)
1318315216.6526 (0.0006)  C>S
---------------------------------------------------------------
HEAD /landing HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

New TCP connection 6: 10.10.72.30(60068) <-> 10.10.70.110(80)
1318315216.6530 (0.0003)  C>S
---------------------------------------------------------------
HEAD / HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

4)  curl -I http://172.28.17.33/login

New TCP connection 7: 172.28.16.50(52288) <-> 172.28.17.33(80)
1318315239.7149 (0.0013)  C>S
---------------------------------------------------------------
HEAD /login HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

New TCP connection 8: 10.10.72.30(52288) <-> 10.10.70.110(80)
1318315239.7152 (0.0002)  C>S
---------------------------------------------------------------
HEAD / HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

5) curl -I http://172.28.17.33/anythingelse

New TCP connection 9: 172.28.16.50(52302) <-> 172.28.17.33(80)
1318315273.0769 (0.0012)  C>S
---------------------------------------------------------------
HEAD /anythingelse HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

New TCP connection 10: 10.10.72.30(52302) <-> 10.10.70.120(80)
1318315273.0774 (0.0003)  C>S
---------------------------------------------------------------
HEAD /anythingelse HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 172.28.17.33
Accept: */*
---------------------------------------------------------------

Mike and nitass,

 

 

Thank you both for your help. I guess I didn't realize the power behind HTTP::uri. I've got it working though I had to set uri to "/" for the default pool as well. The only small issue I'm still having is IE blocks images on the page. If I remove iRule from the VIP, the images are there. Mozilla works fine either way. Any idea?

 

 

Thank you,

 

Roman

If images aren't showing up, odds are you are changing the URIs for image requests as well. You might need to include another case in your switch statement handling images (ie. "*.gif" and leave those URIs alone). You would need to use the "-glob" to allow for wildcards btw...

Joe,

 

 

Thanks a lot for your post. It took me sometime, but I've figured it out ... didn't think about URIs for images (and stylesheets).

 

Great to have such helpful resource as DevCentral

 

 

Roman

 

Great, glad to help! Feel free to ask away if anything else comes up...

Joe,

 

 

Something did come up (not sure if it's the right forum for the question):

 

I had secured WebService with self-signed cert I was calling from my java client via URLConnection. After importing server cert into client keystore and a weak of disabling host and certificate verifications, it all worked fine. The troubles started after I've placed secured server behind BIG IP (created VIP w pool, added secured server as member). Though I can invoke webservice from the browser (after acknowledging risk and accepting self-signed cert), invoking it from code gives me infamous error "unable to find valid certification path to requested target". Do I need to import server self-signed cert into a keystore on F5 machine (Local Traffic/SSL Certificates/Import)? I'm just afraid of blowing things away as F5 is used by others.

 

 

Any help is greatly appreciated

 

Roman

So you are saying that if you connect directly to your secured web service (not through the BIG-IP), you have things working (after keystore configuration), but when you run it through the BIG-IP while your server is still setup as a secure web service and you don't have LTM doing SSL offload, it's not working on your client? If so, that doesn't make sense as if the LTM is not terminating the SSL, then the certificate passing should be identical. The packets to/from the web service from the client shouldn't be changed by the LTM (that is, unless it's terminating the SSL - ie. decrypting from the client and then re-encrypting to the backend server).

 

 

If all you care about is allowing the certs on your client app, the code I wrote for the iControl library for Java might help out. In it, I wrote a class called XTrustProvider that told the ssl client code to allow self-signed certificates. I blogged about it a few years back:

 

 

http://devcentral.f5.com/weblogs/joe/archive/2005/07/06/1345.aspx

 

 

Hope this helps...

 

 

-Joe

 

Joe,

 

 

Sorry for the misleading post: I should have stated I was using BIG IP over SSL. It turned out I was actually missing the BIG IP's self-signed cert on the webserver making WS call. After I've downloaded the cert and imported it into webserver's keystore, it all fell into place. Thank you for your help once again.

 

 

Roman