Forum Discussion

John_Graat_4571's avatar
John_Graat_4571
Icon for Nimbostratus rankNimbostratus
Apr 08, 2010

Connection with client closed but data is still passed to backend server

I have an iRule which protects a backend server for unauthorized access.

 

If the client ip-address does not appear on a whitelist, TCP::respond is called from within

 

CLIENT_ACCEPTED with an "access denied for ".

 

Directly hereafter, TCP::close is called.

 

 

Unauthorized clients do get the 'access denied' message. So far so good.

 

However, the logging of the backend server showed that the data transmitted by the client

 

was still being received by the server. Tcpdump verified that the data is being sent to the server.

 

The server responds (according to tcpdump; I don't log this in the application) and the LTM

 

then ignores the data because there isn't any connection with the client any more.

 

 

I tried using TCP::collect from within CLIENT_ACCEPTED followed by a TCP::payload replace

 

with an empty string from within CLIENT_DATA but that ended in a TCP connection

 

between the LTM and the backend server without any data being transmitted. In this case

 

that was a very bad idea because the backend software wasn't prepared for this.

 

 

Using 'reject' instead of TCP::close seems to solve it but I'm not sure if this is the way to go.

 

 

So the question is, how to close the connection without the original data from the client being

 

passed on to the backend server? Do I have to use 'reject' or is there a better way?

 

 

Thanks,

 

 

John

 

 

3 Replies

  • Hi John,

     

     

    I would have expected TCP::close to work in the CLIENT_ACCEPTED event. Could you try TCP::respond followed by reject? If that doesn't work either, I'd suggest opening a case with F5 Support and ask them for help. If you figure out a solution one way or another, can you reply back here for future reference?

     

     

    Thanks, Aaron
  • Hi Aaron,

     

     

    thanks for the answer. I tested with 'reject' instead of 'TCP::close' and that indeed does prevent the client data from being transmitted to the pool members.

     

     

    John