CSS keepalive TCP flags

Andrew.Gray · ‎07-14-2008

Hi. I have a problem with the way an application behaves in response to CSS tcp keepalives, I'd be grateful for any advice.

Using standard TCP keepalives, an application logs a broken connection for every keepalive, filling up the app logs, causing the administrators to complain. If I change the tcp-close type to FIN, the application doesn't log an error, but it still logs the connection, same complaint from the admins.

The application developers feel that it's not their problem, they're comparing the keepalives to nmap probes and indeed, it is possible to confirm that the service is up with nmap, without generating an error/connection log entry on the server.

According to some Wireshark captures, the TCP flags of a CSS keepalive, compared to an nmap probe, are as follows;

CSS

---

CSS --> Syn --> Server

CSS <-- Syn, Ack <-- Server

CSS --> Ack --> Server

CSS --> Rst, Ack --> Server

nmap -sS

----

NmapPC --> Syn --> Server

NmapPC <-- Syn, Ack <-- Server

NmapPC --> Rst --> Server

So, my question is, can the tcp behaviour of CSS keepalives be modified, to dispense with the arguably superfluous 'ack'ing that's illustrated above?

Thanks

Andy

Syed Iftekhar Ahmed · ‎07-14-2008

If I am remember correctly TCP probe behavior was changed to the current one in 7.2 code.

(Lots of people had to enable tcp-close type Fin due to server errors:)

Prior to that it was similar to the one you mentioned as nmap.

I am afraid there is know way to return to the way it was done before.

One option would be to write a script and use it for probing servers.

Syed

opc.perera · ‎07-14-2008

Andrew,

try modifying the following on the SERVICE configuration :

service XXXXXX

keepalive type tcp

keepalive tcp-close fin

active

Andrew.Gray · ‎07-15-2008

Thanks for the replies.

I've tried tcp-close fin, it stops an error being logged, but the application still logs the connection.

I wouldn't be concerned, other than the fact it clearly is possible to both establish that the service is running on the server and not log the connection attempt, using Nmap's more abbreviated tcp behaviour.

I am curious, though. What is the CSS acknowledging when it sends an ACK in the RST packet?

Regards

Andy