I have a LDAPS VIP that I am offloading SSL on.  I need to then forward that decrypted traffic to another virtual so that I can run a TCP::collect on the unencrypted traffic.  Every example I can find of forwarding to a virtual via an irule uses the HTTP_REQUEST event.  What event can I use that will grab the traffic AFTER the SSL decryption to send it on to the other virtual?

I have tried

when LB_SELECTED {
  virtual vs_LDAP-TEST-CLEAR
}

But this seems to either just forward to the default pool that is assigned to the VIP, or if no pool is assigned, then obviously LB_SELECTED never fires.

running 10.0.1
 
HELP?

Joe

FYI, I found the SSL::collect command which gives me the ability to look at and match on the decrypted traffic right on the original LDAPS VIP. So my issue is resolved. But I am still curious if anyone knows what is the best event to use on a non-HTTP VIP to forward to a virtual. Anyone? CLIENT_ACCEPTED??? what else is there?

TIA,

Joe

so I am not quite there after all. I am using this irule fromt he irule wiki page for SSL::collect:

when CLIENTSSL_HANDSHAKE {
log local0. "[IP::client_addr]:[TCP::client_port]: SSL handshake completed, collecting SSL payload"
SSL::collect
}
when CLIENTSSL_DATA {
log local0. "[IP::client_addr]:[TCP::client_port]: Collected [SSL::payload length] bytes, releasing payload"
log local0. "\[SSL::payload\]: [SSL::payload]"
SSL::release
}

However I am only seeing the initial LDAP bind and nothing more. I really need to see the query. I think this is because I am only "collecting" the first packet(s) after the SSL handshake and not the client-to-server packet that contains the query. so again, what event to use to "collect" all client SSL::payloads so that I can see the LDAP query?

Joe

To solve the problem directly asked, you're calling SSL::release in CLIENTSSL_DATA, so you're telling the BIG-IP to stop collecting data, so it's no surprise that that's what it's doing. You'd want to do something like:

when CLIENTSSL_DATA {
  if { [SSL::payload] contains "the query string" } {
      log local0. "I got the query!"
      SSL::release
  } else {
      SSL::collect
  }
}

That said, what are you hoping to do with the LDAP query? If it involves making a pool selection or other load-balancing decision, then you'll probably run into bug 224958 (which basically says that the connection isn't held up by SSL::collect, and it should be) if you keep going with the SSL::collect route (which, under ordinary circumstances, would be your best bet). You might be able to get away with doing an LB::detach before doing your selection, or doing an LB::reselect or something, but you might not; you'd just have to try for sure. If you want to go down your original route, then you can just do a "virtual other_virtual" command right at CLIENT_ACCEPTED if you always want SSL-decrypted traffic to be send to that other VIP. There's no better event to do that in in this case. Hope this helps!

Spark,

Thanks for the info. Not looking to make an LB decision just log the query and source address. This is more of a troubleshooting issue. We have a LDAP client that is making a large query every 30 seconds, that query takes over 10 minutes to return. Needless to say, our LDAP servers quickly run out of memory and we end up with an LDAP outage. We are having a tough time identifying this client because the VIP was originally a L4 forwarding VIP with the SSL terminating on the servers AND, since the LTM is not inline, we are SNAT'ing the VIP.

So the SSL::collect command doesn't "hold" the connection like the TCP::collect command? Guess that explains the lack of the skip bytes option like TCP::collect has. i.e. TCP::collect 200 10

So if I understand, your irule will essentially continuously collect the SSL data until it sees the match string while still allowing that data to pass through the VIP onto the servers. Is that an accurate statement?

Thanks for your help.

Joe

The SSL::collect command doesn't "hold" the connection like the TCP::collect command, that's correct. However, the "skip bytes" option to TCP::collect.... is a long and complicated story that I won't go into right now, since it'll only confuse the issue. Suffice to say, that's not a model we're likely to emulate going forward. The iRule above will "continuously collect the SSL data until it sees the match string", yes, but won't send the data to the server until SSL::release is called (note that there's an implicit "SSL::release" at the end of CLIENTSSL_DATA if you don't do anything else). The *connection* will get "sent" to the server, but the data won't. If you want to pass on the data while still collecting it, you'd have to do something like:

append payload [SSL::payload]
SSL::release
if { $payload contains "string" } {
   log local0. "Found it!"
} else {
   SSL::collect
}

but I haven't tested this exact code.