Application and transport Layer connection problems

[tech]

I am running a redundant setup: PIX 515E 6.3(1). I am having the following problems to servers on the Intenet but only from certain sites.

FTP - Finishes the 3 way handshake and the 4th packet which serves the login prompt takes about 90 seconds to appear. Once the login prompt appears, FTP operation is normal in speed.

HTTP - This happens about every 1 to 4 hours. The SYN and SYN,ACK takes place fine. The client that should send the ACK to finish the 3 way handshake sends a RST instead.

SSH - 3 way handshake is fine, keys exchanged, but the home directory prompt takes 90 to 180 seconds to appear after a successful login. If the password is incorrect, then the session will terminate in a normal amount of time.

I have tested a system in front of the firewall and all scenrios work fine. I have also tested both firewalls one at a time to rule out a hardware problem on only one PIX.

I noticed these problems occuring with great frequency the next day after I upgraded the DES key to a 3DES/AES key. Has anyone seen this before? Should I apply for another key possibly? I have seen these problems in a much lesser frequency even before I upgraded the key so I am not sure this is the problem.

Thanks,

RJ

[mostiguy · Accepted solution]

these could be reverse dns problems - ssh is notorious for taking forever to login to when the ssh server cannot do a reverse dns lookup of the host you are connecting with.

basically, if "nslookup your.client.ip.here" does not return a hostname, that is quite possibly the problem

[tech]

You hit it right on!!

Our reverse zone was delegated to our name server about 12 days ago since we have a < /24.

Unfortunately, the ISP and our name server had a syntax difference on the name of the reverse zone which resulted in PTR failures. As soon as I fixed the syntax all starting working correctly.

Thanks again as this problem has been driving me nuts for the last 12 days. This is the most useful and helpful newsgroup I have ever used.

Thanks a ton!!

RJ

[ehirsel · Accepted solution]

Run two capture traces on the pix at the same time, one for the inside interface where the clients sit, and one for the outside interface.

Also look at the firewall logs, I wonder if you see requests from the external hosts on tcp port 113, which is the ident protocol. If you do and they are from the sites that have trouble, code service resetinbound on your pix to let the other end know to stop running ident processing. This normally is seen with mail/smtp services.

Apply access-lists that define interesting traffic, so you won't capture everything. Then compare the traces and see if you see a delay in one trace that you don't in another.

This is in regards to the http issue; the client sending the reset packet should be your client. I suspect that one of the ip addresses in the syn ack packet is not the same as the syn seq packet; thus the reset being sent. Asymetric routing (either at the server end, or the client end) could be the cause of that, where one path uses a firewall with nat/pat and the other does not.

Let me know if the capture traces were helpful.

[tech]

The reverse DNS solved the SSH and FTP issues. You are right on the HTTP issue. The server is a monitoring server. It uses a PAT to go out and check the Internet and uses a static PAT for hosts on the outside to receive other services. Also, I did set up service resetinbound in my config as I did see a lot of 113 requests to my mail server. Thanks a lot for the information. I have never received 2 replies that covered all of my questions. Thanks again!

RJ