Forum Discussion

Jeff_Mattson_44's avatar
Jeff_Mattson_44
Icon for Nimbostratus rankNimbostratus
Jan 24, 2007

SSL termination -- race condition?

Hi,

 

I'm using Big-IP v9.1.2.

 

 

I have a virtual with a basic client ssl profile but without a default pool.

 

 

I'm setting the destination in an irule using a node statement in the CLIENTSSL_HANDSHAKE event.

 

 

As soon as the ssl handshake is completed (successfully), the client gets a tcp-reset packet (The Big-IP never tries to reach the server; the log shows the log statement from the irule).

 

 

Interestingly, I can get a good connection in any of the following situations:

 

(1) the ssl client requests a weak cipher, like the 40-bit Export algorithms.

 

(2) an http virtual uses an http profile (I'm not using http; I just tested behavior with it).

 

(3) the virtual has a default pool.

 

 

It seems like the node command in the CLIENTSSL_HANDSHAKE event doesn't execute before the F5 expects to have a destination. I'm curious as to why it works with the Export ciphers and not any others?

 

 

Ultimately, I need to direct traffic based on decrypted SSL payload, via Stream::collect or however it is made available. I'm concerned that maybe this tcp reset will affect me when we get to that point.

 

 

Perhaps newer version's have addressed this? I'm going to upgrade and test, but thought I'd ask now anyhow, since I'm probably just missing something fundamental.

 

 

Thanks for any clarification.

 

application delivery
dev
devops
iRules

3 Replies

Sort By
  • Jeff_Mattson_44's avatar
    Jeff_Mattson_44
    Icon for Nimbostratus rankNimbostratus
    Feb 05, 2007
    Thanks, Colin. Sorry for the delay on this.

    The problem is pretty simple to reproduce. I just have a virtual server listening on 443 with a default ssl profile...no http profile and no default pool. I attach the following irule to the virtual server.

    
when CLIENTSSL_HANDSHAKE {  
  log "in CLIENTSSL_HANDSHAKE"
  use node 192.168.100.7 80
}

    It does seem strange. I haven't tried it yet on an updated version. Again, I ultimately need to use info in the first data packet after the handshake to select a destination server. Currently I'm using the "middle-man virtual server" technique described by unRuleY in this forum. Of course, that is a hard sell to other network admins...sounds a bit ad hoc for an F5.

    Thank you,

    Jeff
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Feb 08, 2007
    I'm still a little confused as to why the node command won't work for you there. Have you tried removing the "use" in front of the node command? I don't think it should break the rule, especially not in the way you're seeing...but when at a loss, grab for straws, right? :p

     

     

    Is this node an address the BIG-IP can talk to?

     

     

    Strange stuff...

     

     

    Colin
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    Feb 14, 2007
    Does the virtual server status show "red?" I believe that prior to 9.2 if a virtual server did not have a default pool assigned, it would show as "down" and therefore send a reset packet. I ran into this several times when I had a rule on a port 80 vip that simply redirected everything to 443. Even though there was no chance of any traffic being sent to a pool with that rule, I still had to define a default pool to get the vip to work. I think this was fixed in 9.2.

     

     

    Denny