For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Richard_Bedford's avatar
Richard_Bedford
Icon for Nimbostratus rankNimbostratus
Mar 27, 2008

Confirming LTM node persistence between pools?

Hi All,

 

 

Currently have an LTM (9.4) load balancing a group of IIS/Sharepoint sites. We originally had problems with being able to 'save' (post) information to the site but have formulated a fix by enabling SSL on the IIS servers and using the following (and I appreciate that a better solution would be to 'fix' the application...):

 

 

* an HTTP profile set with rechunk and header-erase 'Accept-Encoding'

 

* a streams profile to change http://nameofsite to https://nameofsite

 

* a persistence profile using client IP address and a time-out of 1200s

 

* the following iRule:

 

 

when HTTP_REQUEST {

 

Look for the 'POST' method - a client is posting data back to the portal

 

if { [HTTP::method] equals "POST" } {

 

Set the LTM pool to the 'SSL' enabled pool

 

pool SPS_SSL_pool

 

}

 

else {

 

Not a 'POST'...

 

Disable the LTM-to-server SSL profile (so LTM talks in the clear to IIS)

 

SSL::disable serverside

 

Select the HTTP only pool

 

pool SPS_HTTP_pool

 

}

 

}

 

 

The two pools are made up of the same servers, but one pool is on port 80 only, and the other is port 443 (we've enable SSL on IIS).

 

 

Question: we want to ensure that when a client posts data, it's actually sent to the same node in the SSL pool that it was using in the http-only pool. Will the persistence profile take care of this, even though we're switching pools and services? (looking at the stats seems to indicate this, but those higher up need an definitive answer before we can implement this as a fix).

 

 

Cheers,

 

 

Richard
application delivery
dev
devops
iRules

4 Replies

  • Nicolas_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    Mar 27, 2008
    Hi,

    Since you use different pools it should not work but you may do the following:

    
when HTTP_REQUEST {
  set IP_ADDR [session lookup uie [IP::client_addr]]
   Look for the 'POST' method - a client is posting data back to the portal
  if { [HTTP::method] equals "POST" } {
    if {$IP_ADDR == ""} {
       Set the LTM pool to the 'SSL' enabled pool
      pool SPS_SSL_pool
    } else {
      pool SPS_SSL_pool $IP_ADDR 443
    } 
  }
  else {
     Not a 'POST'...
     Disable the LTM-to-server SSL profile (so LTM talks in the clear to IIS)
    SSL::disable serverside
     Select the HTTP only pool
    if {$IP_ADDR == ""} {
      pool SPS_HTTP_pool
    } else {
      pool SPS_HTTP_pool $IP_ADDR 80
    }
  }
}
when LB_SELECTED {
  session add uie [IP::client_addr] [LB::server addr] 1200
}

    I don't have time to test it but should be ok !

    HTH
  • Richard_Bedford's avatar
    Richard_Bedford
    Icon for Nimbostratus rankNimbostratus
    Mar 27, 2008
    Hi nmenant,

     

     

    I can see what you're trying to do (I think - not an expert on iRules). You're basically trying to record the node selected when the LTM does it's thing with the HTTP session, and then re-read the node details and apply when using SSL at the backend (when it's a post).

     

     

    Except the LTM moans with a 'Prerequisite operation not in progress' type error - I think this is a chicken and egg situation:

     

    The first 'set IP_ADDR... line tries to retrieve the information recorded by the 'when LB_SELECTED' statement, except we haven't chosen a pool at that point, so the session data it's trying to read isn't there.

     

     

    Does this make sense?

     

     

    I managed to get around this by setting a default (HTTP) pool. But now I can't save my data (my original problem with Sharepoint) :-(

     

     

    I'm looking into the options - thanks for the tips.

     

     

    Cheers,

     

     

    Richard

     

  • Nicolas_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    Mar 27, 2008
    Hi,

     

     

    You are right but here is why i do such a test: if {$IP_ADDR == ""} because it means that if there is not already any entry for this IP then we should do the default load balancing

     

     

    So it should work Oo

     

     

    Could you copy paste the exact error message you have ?

     

     

    Thanks
  • Richard_Bedford's avatar
    Richard_Bedford
    Icon for Nimbostratus rankNimbostratus
    Mar 28, 2008
    Hi nmenant,

    I think I've managed to sort it. It appears to have been a typo in your iRules. I've modified the rules so it now looks like this:

    when HTTP_REQUEST {
set IP_ADDR [session lookup uie [IP::client_addr]]
log local0.info "--SPSTEST-- session lookup data IP_ADDR = $IP_ADDR and IP_client_addr = [IP::client_addr]"
 Look for the 'POST' method - a client is posting data back to the portal
if { [HTTP::method] equals "POST" } {
if {$IP_ADDR == ""} {
 Set the LTM pool to the 'SSL' enabled pool
pool SPS_SSL_pool
log local0.info "--SPSTEST-- SSL Chosen for [HTTP::method] ip_addr = IP_ADDR$"
} else {
pool SPS_SSL_pool member $IP_ADDR 443
log local0.info "--SPSTEST-- SSL Chosen for [HTTP::method] and pool node $IP_ADDR"
} 
}
else {
 Not a 'POST'...
 Disable the LTM-to-server SSL profile (so LTM talks in the clear to IIS)
SSL::disable serverside
 Select the HTTP only pool
if {$IP_ADDR == ""} {
pool SPS_HTTP_pool
} else {
pool SPS_HTTP_pool member $IP_ADDR 80
}
}
}
when LB_SELECTED {
session add uie [IP::client_addr] [LB::server addr] 1200
}

    I think the problem was with the 'pool' command when you selected the specific IP_ADDR$ member. The keyword 'member' was missing.

    Examining the logs it all seems to work a treat now - I'm seeing the client stick to the same IIS server through http and https.

    I'm also guessing I no longer need a default persistence profile as the client address is recorded with a timeout of 1200s? It seems to work fine without this.

    Many, many thanks for you help on this - it's much appreciated.

    Cheers,

    Richard