Loosing packets when passing data from the inside interface to the out

[fdina]

Hi,
I have a two interface PIX firewall using NAT to to give my private address access to the internet. I have servers on the outside interface that are accesible from the servers in the inside interface by using static and conduit commands. The problem is that data transfers from the inside servers to the outside servers get broken after a few KBs of transfers. It happens for ftp, smtp, SQL Server's 1433 port and NETBIOS file sharing ports. Transfers from the outside to the inside happens OK, and the most striking fact is that transfers from the inside servers to the internet cloud (ie, out of my internet router) succeed.
I did a dumping of the packets during a ftp get command runned from a external client hitting a internal server. After 900K transferred the packets sent by the ftp server doesnt reach the client. The control connection is still alive. You can restart the get command and the situation repeats...
What can be wrong...?
This happens to a PIX 515 running the OS version 4.4(7)

Can somebody give me a hint where to investigate about this problem?
Thanks in advance
Faustino

 

[yizhar]

HI.

An important troubleshooting tool is Syslog messages.
A simple way to get some info:

logging on
logging buffer x (use a value of 4-6)
show log

Post here your pix config and relevant syslog messages if you get some, then maybe we can help you find the problem.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[fdina]

I published the syslog and tcpdump logs recorded in a failed ftp session that reproduces the error. All the data is published in:

http://www.geocities.com/pixerror

So, any suggestion on what to do further will be very appreciated

Thanks for your help
Faustino

 

[yizhar]

HI.

Please read the following articles:

http://www.cisco.com/warp/public/110/21.html

http://www.cisco.com/warp/public/110/2.html

I would go for the reverse DNS problem because I don't see any blocked TCP 113 in your syslog output.

Bye


Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[fdina]

Yizhar,

The reverse DNS problem was my first suspect. I read about it when checking the pix documentation. After a long fight with our internet provider we could fix our reverse dns resolution but nothing changed. Anyway let me check with you our resolution. Suppose my domain is mydomain.com.mx Nowadays the resolution is the following:
for the pix outside interface: pix.mydomain.com.mx
for the external machine: host5.mydomain.com.mx
for the internal machine: host4.mydomain.com.mx

Today I have been investigating an advise. Some guy told me that he saw similar problems cause of mismatch of the interfaces between the pix and the switches. The advise was to fix the interfaces on both sides on the pix and the switches. My pix was configured to 100full on both interfaces. The switch connected to the outer interface only allows connections from devices with auto-negotiation, so I changed it for a 10BaseT hub and set the pix's outer interface to the corresponding 10baset and the improvement is signifficant. Now in a 40% of cases I can download successfully my test data. Before I never could get more than 1.5MB (6MB size) in any download.
I'll try to fix the interface on the firewall connected to the inner interface of the pix and look for the results. May be we are on the track.

Thanks a lot for your help
Faustino

 

[yizhar]

HI.

Did you try putting back the 10/100 switch and simply setting the pix interface to "auto"?

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar