Default pool

I'm confused. You are asking whether you can assign the pool based on conditions, and your first example does just that. Then you say you are doing it in the second example, but that code doesn't use the pool command at all. And, in the second example you are saying you cannot do a URI check, but that's what you did in the first example...

 

 

From what I can tell, your first example should route to the pool server_group_a if any of the conditions are met. Maybe it's your mixing of "and" and "or"s. I would recommend redoing the first example to as follows:

 

 

when HTTP_REQUEST {
  if [matchclass [IP::client_addr] equals $::DVW] } {
    switch -glob [HTTP::uri] {
      "/NGQMRepository_com*" -
      "/NGQMRepository_res*" -
      "/q4*" -
      "/QMSCTWeb*" -
      "/qmwise4*" -
      "/repxcl4*" -
      "/SCPCentral*" -
      "/SCPIntermediarySrvce*" -
      "/SCPRemote*" -
      "/2004content*" -
      "/Faculty_Virtual*" {
        pool server_group_a
      }
    }
  }
}

 

 

The "-" at the end of each switch case acts as an "or" between all the comparison values. So, this code should pass traffic to the pool server_group_a for all client IPs in the DVW class AND the URI begins with one of the values (because of the "*" in the glob expression for each test).

 

 

If I have it wrong, then if you present a detailed explanation of the possible inputs and the desired results we can try to help you out further.

 

 

-Joe

When I get back to work I will try rewriting as you suggest and present a detailed explanation.

I see. Yes both examples assign a pool based on the conditions. However, the second example reacts differently than the first. Essentially, if the pool command reacted the same in the HTTP_REQUEST event as it does in the CLIENT_ACCEPTED event; the rule would work. The CLIENT_ACCEPTED event seems to set the default pool correctly where the HTTP_REQUEST event doesn't, however the CLIENT_ACCEPTED event is inadequate for the checks needed. I need the rule to set the default group as it does when using the CLIENT_ACCEPTED event, but also providing both the IP address and uri checks in the HTTP_REQUEST event. I also tried rewriting the check as previously suggested but, it doesn't change how the rule reacts.

 

 

Here are detailed examples of each scenario.

 

 

The first example, which I am using now, does exactly what it is intended to do until you try inserting certificates in the http header for the backend servers. The header insert gets lost, when users don't put the trailing slash on the url, unless a "default group" that is selected through the GUI is the server pool where traffic is headed. This is what the rule looks like.

 

 

 

when CLIENTSSL_CLIENTCERT {

 

set cur [SSL::sessionid]

 

session add ssl $cur [SSL::cert 0] 180

 

}

 

when HTTP_REQUEST {

 

set id [SSL::sessionid]

 

set the_cert [session lookup ssl [SSL::sessionid]]

 

 

if { $the_cert != "" } {

 

HTTP::header replace CertSubject [X509::subject $the_cert]

 

}

 

if { [matchclass [IP::client_addr] equals $::DVW] and

 

[HTTP::uri] starts_with "/NGQMRepository_com" or

 

[HTTP::uri] starts_with "/NGQMRepository_res" or

 

[HTTP::uri] starts_with "/q4" or

 

[HTTP::uri] starts_with "/QMSCTWeb" or

 

[HTTP::uri] starts_with "/qmwise4" or

 

[HTTP::uri] starts_with "/repxcl4" or

 

[HTTP::uri] starts_with "/SCPCentral" or

 

[HTTP::uri] starts_with "/SCPIntermediarySrvce" or

 

[HTTP::uri] starts_with "/SCPRemote" or

 

[HTTP::uri] starts_with "/2004content" or

 

[HTTP::uri] starts_with "/Faculty_Virtual"} {

 

use pool server_group_a

 

}

 

elseif { [matchclass [IP::client_addr] equals $::MIL] and

 

[HTTP::uri] starts_with "/NGQMRepository_com" or

 

[HTTP::uri] starts_with "/NGQMRepository_res" or

 

[HTTP::uri] starts_with "/q4" or

 

[HTTP::uri] starts_with "/QMSCTWeb" or

 

[HTTP::uri] starts_with "/qmwise4" or

 

[HTTP::uri] starts_with "/repxcl4" or

 

[HTTP::uri] starts_with "/SCPCentral" or

 

[HTTP::uri] starts_with "/SCPIntermediarySrvce" or

 

[HTTP::uri] starts_with "/SCPRemote" or

 

[HTTP::uri] starts_with "/2004content" or

 

[HTTP::uri] starts_with "/Faculty_Virtual"} {

 

use pool server_group_b

 

}

 

}

 

 

The second example reacts similarly to setting the "default group" selection in the GUI. The header inserts do not get lost when going to a different server pool than the selection in the GUI. But, the Client_Accepted event does not allow for uri commands. Incoming traffic needs to match both the IP address and the uri to direct the traffic as some ip addresses are in multiple groups. This is what that rule looks like.

 

 

when CLIENTSSL_CLIENTCERT {

 

set cur [SSL::sessionid]

 

session add ssl $cur [SSL::cert 0] 180

 

}

 

when CLIENT_ACCEPTED {

 

if { [matchclass [IP::client_addr] equals $::DVW] } {

 

use pool server_group_a

 

}

 

elseif { [matchclass [IP::client_addr] equals $::MIL] } {

 

use pool server_group_b

 

}

 

}

 

when HTTP_REQUEST {

 

set id [SSL::sessionid]

 

set the_cert [session lookup ssl [SSL::sessionid]]

 

 

if { $the_cert != "" } {

 

HTTP::header replace CertSubject [X509::subject $the_cert]

 

}

 

if { [matchclass [IP::client_addr] equals $::DVW] and

 

[HTTP::uri] starts_with "/NGQMRepository_com" or

 

[HTTP::uri] starts_with "/NGQMRepository_res" or

 

[HTTP::uri] starts_with "/q4" or

 

[HTTP::uri] starts_with "/QMSCTWeb" or

 

[HTTP::uri] starts_with "/qmwise4" or

 

[HTTP::uri] starts_with "/repxcl4" or

 

[HTTP::uri] starts_with "/SCPCentral" or

 

[HTTP::uri] starts_with "/SCPIntermediarySrvce" or

 

[HTTP::uri] starts_with "/SCPRemote" or

 

[HTTP::uri] starts_with "/2004content" or

 

[HTTP::uri] starts_with "/Faculty_Virtual"} {

 

use pool server_group_a

 

}

 

elseif { [matchclass [IP::client_addr] equals $::MIL] and

 

[HTTP::uri] starts_with "/NGQMRepository_com" or

 

[HTTP::uri] starts_with "/NGQMRepository_res" or

 

[HTTP::uri] starts_with "/q4" or

 

[HTTP::uri] starts_with "/QMSCTWeb" or

 

[HTTP::uri] starts_with "/qmwise4" or

 

[HTTP::uri] starts_with "/repxcl4" or

 

[HTTP::uri] starts_with "/SCPCentral" or

 

[HTTP::uri] starts_with "/SCPIntermediarySrvce" or

 

[HTTP::uri] starts_with "/SCPRemote" or

 

[HTTP::uri] starts_with "/2004content" or

 

[HTTP::uri] starts_with "/Faculty_Virtual"} {

 

use pool server_group_b

 

}

 

}

 

 

I tried forcing a trailing slash onto the incoming uri which solves the header problem, but the website doesn't like it. More than half the redirects in the site don't work once the user is on the site.