Pix "seems" to reply to tcp/ip built-in keep alive in a Win environment

isabella007 · ‎06-14-2005

We have a PIX-515 64Mb RAM, Software Version 7.0(1). This is an odd problem we have seen and can't quite come up with an explanation. Our apps attempt to keep permanent TCP/IP connections to other host. For that, we have added a 60 sec KEEP ALIVE to each socket to determine when the link goes away. Specially, to get around inactivity timer in Pix. We run traces on both hosts and don't see the KEEP alive reply from server host, YET, client host is receiving a valid KEEP alive reply from somewhere. This problem only happens if we put the Pix in between. Questions:

1- Does Pix consider this KEEP alive polling (Winsock) as "traffic". Therefore, it should be sufficient to keep the connection alive? PUSH flag is not set in these packets. In addition, Winsock decreases current sequence number by one to "fake" a real packet.

2- Can the Pix really issue a "reply" to these Keep alive packets. That would be odd.... We just can't find other explanation. Thanks.

2-

aacole · ‎06-15-2005

Have you used debug packet on the PIX to trace this during a quiet period? It may give you a clue as to the type of packet being sent back to the Host.

If you take the pix out and run the same trace do you see the keepalive replies from the server host?

I would have thought the only packet the PIX would issue as the `reply' may be an ICMP packet due to some error, the packet trace may show this. Also you could try debug icmp trace, may show something of interest?

isabella007 · ‎06-17-2005

No, I have not. I'll turn it on to see what's coming across. If I take the pix out, I see keep alive replies from the server host. The trace at the server host shows these packets too. This is very odd. I posted this problem thinking that people might have seen this before. Specially, with all of the problems that inactivity timers cause. I'll turn debug on and will post results.

Thanks.

isabella007 · ‎06-28-2005

My apologies but in version 7.0, we can't find a debug command to see tcp/ip traffic. I used to use "debug packet" in earlier versions...But, have they dropped this command? incredible... Sorry but I am not a guru when it comes to Firewalls. We are working on this problem again and have a theory. The Pix might be doing some caching .... the Keep alive request is sent out over and over... again... Could it be the Pix thinks that there is a "reply" packet in cache for the same packet..... I don't know .. it's weird.

Thanks.

isabella007 · ‎06-29-2005

Hi,

I think we have discovered the problem. For every connection made from inside to outside or viceversa. Pix "appears" to be creating a brand new connection to remote host. While this should not be a problem because data is relayed back and forth. Problem lies in the fact that KEEP_ALIVE packets are not considered part of the data stream. As a result, if a connection is made to from inside to a remote host, KEEP ALIVE queries never reach the end host because pix would not forward these queries. In other words, Pix replies to these queries directly.

I guess this has to do with the fact that KEEP alive packets do not have the "PUSH" flag set and therefore are not considered part of the data stream. In other words, there is no way to detect a dead connection on the other end (e.g power failure, hard shutdown, etc) because the Pix always replies to the KEEP ALIVE but does not forward these queries. Any way around this????? really it defeats the purpose of the KEEP alive. We're using Windows Keep alive implementation, the one built-in in the stack. I would greatly appreciate your comments.

Thanks.

Mauricio

isabella007 · ‎07-31-2005

Just for the record, this was a bug in 7.0(1), please see bug # CSCei27053. If you experience this problem, upgrade to IOS 7.0(2) released on July 2005.