Forum Discussion
Moe_Jartin
Cirrus
CirrusWhat event to use to forward to virtual?
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
Moe_JartinFYI, 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- Moe_Jartinso 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 - Moe_JartinSpark,
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