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

3 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Apr 26, 2014

    I may be missing your intention, but is there a specific reason why you wouldn't want to use a clone pool? You can assign that clone pool to the VIP, separate client side and server side clone pools to the VIP, or trigger a clone pool via an iRule.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Apr 29, 2014

    Okay, here's the thing about clone pools. They basically sit somewhere at the edge of both sides of the proxy. If you have client side SSL, a client side clone pool cannot see unencrypted traffic because at that point it hasn't been decrypted yet. If you have server side SSL, a server side clone pool can't see unencrypted traffic because at that point it has already been encrypted on its way to the server. The clone command in iRules actually works in the server side context, so the above still applies. If you're offloading SSL at the proxy (and not re-encrypting), then you can see decrypted traffic in the server side clone pool, but it is post-translation. That means the destination address has changed, and optionally the source if SNAT is applied. Plus if any iRules or other modules have acted on the data, you'll see that too. You then have a few options:

    1. VIP targeting - this is where you have an external and an internal virtual server and pass traffic flow from outer to inner via the virtual command in an iRule. 

      when CLIENT_ACCEPTED {
    virtual simple-443-int-vs
}

      The external VIP offloads SSL on the client side, the internal VIP re-encrypts on the server side, and your clone pool can either sit on the server side of the external or client side of the internal VIPs. Any proxy logic or other iRule processing you may have should be done on the inner VIP to avoid seeing that in the cloned data.

    2. Sideband - this is where, in a single VIP, you issue a sideband process fork and send some piece of data somewhere out of the normal path. This is all done in iRules and can be applied at pretty much any event, as long as that event exposes the data you want to send. Generally speaking a sideband call, unlike a clone pool, is a dialog, so it's expecting a response. You can optionally shunt that response expectation in the sideband logic so that it's just pumping data to the destination. A sideband, unlike a clone pool, is also more CPU intensive, so you would need to take that into consideration with this approach. The trade-off is that you have more flexibility in what and when you send payload data.