SSO and iRules

Are you talking about an iRule for a monitor (since you mentioned marking the pool as down)?

Yeah, I meant Health monitor.

My observation is that 98% of the time, an HTTPS monitor is going to fail because of the SSL handshake. The important first step then is to understand where exactly it's failing. If you have access to the server side VLAN, between the BIG-IP and servers, launch an SSLDUMP and listen to the SSL handshakes:

ssldump -AdNn -i [interface or VLAN name] port 443 [and any additional capture filters]

You'll very likely see something wrong here, either side sending an alert or reset and some important step of the process. Alternatively you can attempt to simulate an SSL monitor request directly from the command line. You can either use cURL or openssl s_client. The latter will give you more flexibility in the SSL handshake parameters.

openssl s_client -connect x.x.x.x:443

where x.x.x.x is the server's IP. If the SSL/TLS handshake succeeds, you can then manually issue the HTTP GET request. The following is a minimal example:

GET / HTTP/1.1
Host: www.foo.com
[skip a line]

If that returns a valid HTTP response, an no SSL errors were seen in the SSLDUMP capture, plan C is to attempt to decrypt that SSL between the two parties, also with SSLDUMP, and to see if the HTTP request (and response) are what you expect them to be.

If Kevin's answer doesn't solve it, then you can enable monitor logging and watch the log for the RECV string (see SOL12531 for info on troubleshooting monitors).

• Open the pool that is having the problem (let's call it MY_POOL)
• Make sure the monitor is active on the pool (let's call it MY_MONITOR)
• On the

  Members

  tab in the pool settings, click on one of the members (let's call it 10.0.0.1:3389)
• Enable the checkbox for

  Monitor Logging

• Open an SSH session (I use Putty to connect) to the device and log in to the shell.
  • Run the command

    cd /var/log/monitors

  • Run the command

    ls -l

  • Look for the file referencing your pool and member (most likely in our example it'd be something like

    _Common_MY_MONITOR__Common_10.0.0.1_3389.log

    )
  • Run the command

    tail -f FILENAME

    (where FILENAME is the log filename)
  • It may be visible immediately, but you should see where the monitor sends the request to the server (and you'll see the

    send

    string), and you're looking for the

    recv

    string that comes back.
  • Take that

    recv

    string and update the monitor and see if the pool member(s) show up green again.
• Go back in and disable the monitor logging for that member so you don't have excessive logging filling up space.

This should help figure it out. If your log file ever looks like it's not updating, delete the file and remove the monitor from the pool and re-add it. I've found that will kick it back on again.

I'd like to thank everyone for their replies. I believe I have a working monitor for the SSO sites. I am using:

Send String:    HEAD / HTTP/1.0\r\n\r\n
Receive String: Server\:

On the few servers I have tested it seemed to work. I cannot test on a live environment presently so all my testing is happening on new servers when they get setup.

Thanks again for everyone who has responded.