Connections from the outside interface to the inside get broken prematurely

[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. 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.

Can somebody give me a hint where to investigate about this problem?

Thanks in advance

Faustino

[yusuff]

Use the packet capture utility in PIX 6.2 and see if there are any bad packets, which might be causing the abrupt disconnectivity.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/sysmgmt.htm#xtocid42

HTH

R/Yusuf

[fdina]

My PIX 515 is running the version 4.4(7) and I don't think I would receive permission to upgrade. I'is any freeware packet capture utility available in the internet? It's any serious bug with the 4.4 version that justificates an upgrade?

Thanks in advance

Faustino

[fdina]

Ok,

I did a dumping of the packets during the ftp get command running.

fdina is the inner server, allowed by using conduit and static. It is running ftp. terserver is the ftp client. It is located on the outside interface of the pix.

After 900K transferred the packets sent by the ftp server (fdina) doesn't reach the client and the server resets the data channel(fdina.1249 > terserver.2302). But the control connection is still alive (fdina.21 > terserver.2298). You can restart the get command and the situation repeats...

What can be wrong...?

Follows the final lines of the dumps of the client and server. (Note time are not in sync)

inner server dump:

10:43:45.807637 fdina.1249 > terserver.2302: P 925205:926665(1460) ack 1 win 17520 (DF) (ttl 128, id 4986, len 1500)

10:43:45.807647 fdina.1249 > terserver.2302: . 926665:928125(1460) ack 1 win 17520 (DF) (ttl 128, id 4987, len 1500)

10:43:45.808572 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 926665 win 17520 (DF) (ttl 128, id 11803, len 40)

10:43:45.808636 fdina.1249 > terserver.2302: . 928125:929585(1460) ack 1 win 17520 (DF) (ttl 128, id 4988, len 1500)

10:43:45.809556 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 929585 win 17520 (DF) (ttl 128, id 11804, len 40)

10:43:45.809621 fdina.1249 > terserver.2302: . 929585:931045(1460) ack 1 win 17520 (DF) (ttl 128, id 4989, len 1500)

10:43:45.809631 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4990, len 1500)

10:43:45.809643 fdina.1249 > terserver.2302: P 932505:933965(1460) ack 1 win 17520 (DF) (ttl 128, id 4991, len 1500)

10:43:45.810558 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 931045 win 17520 (DF) (ttl 128, id 11805, len 40)

10:43:45.810579 fdina.1249 > terserver.2302: . 933965:935425(1460) ack 1 win 17520 (DF) (ttl 128, id 4992, len 1500)

10:43:46.105781 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4993, len 1500)

10:43:46.706667 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4994, len 1500)

10:43:47.908361 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4998, len 1500)

10:43:50.311825 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4999, len 1500)

10:43:55.118700 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 5000, len 1500)

10:44:04.773172 fdina.21 > terserver.2298: P 115:187(72) ack 49 win 17317 (DF) (ttl 128, id 5001, len 112)

10:44:04.910306 terserver.2298 > fdina.21: . [tcp sum ok] 49:49(0) ack 187 win 16745 (DF) (ttl 128, id 11819, len 40)

10:44:45.890605 terserver.2302 > fdina.1249: F [tcp sum ok] 1:1(0) ack 933965 win 17520 (DF) (ttl 128, id 11841, len 40)

10:44:45.891903 fdina.1249 > terserver.2302: R [tcp sum ok] 3909102027:3909102027(0) win 0 (ttl 128, id 5004, len 40)

outer client dump:

10:43:15.628355 fdina.1249 > terserver.2302: P 925205:926665(1460) ack 1 win 17520 (DF) (ttl 128, id 4986, len 1500)

10:43:15.628411 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 926665 win 17520 (DF) (ttl 128, id 11803, len 40)

10:43:15.628480 fdina.1249 > terserver.2302: . 926665:928125(1460) ack 1 win 17520 (DF) (ttl 128, id 4987, len 1500)

10:43:15.629341 fdina.1249 > terserver.2302: . 928125:929585(1460) ack 1 win 17520 (DF) (ttl 128, id 4988, len 1500)

10:43:15.629388 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 929585 win 17520 (DF) (ttl 128, id 11804, len 40)

10:43:15.630349 fdina.1249 > terserver.2302: . 929585:931045(1460) ack 1 win 17520 (DF) (ttl 128, id 4989, len 1500)

10:43:15.630400 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 931045 win 17520 (DF) (ttl 128, id 11805, len 40)

10:43:15.630473 fdina.1249 > terserver.2302: . 931045:932505(1460) ack 1 win 17520 (DF) (ttl 128, id 4990, len 1500)

10:43:15.630601 fdina.1249 > terserver.2302: P 932505:933965(1460) ack 1 win 17520 (DF) (ttl 128, id 4991, len 1500)

10:43:15.630630 terserver.2302 > fdina.1249: . [tcp sum ok] 1:1(0) ack 933965 win 17520 (DF) (ttl 128, id 11806, len 40)

10:43:34.593281 fdina.21 > terserver.2298: P 115:187(72) ack 49 win 17317 (DF) (ttl 128, id 5001, len 112)

10:43:34.730004 terserver.2298 > fdina.21: . [tcp sum ok] 49:49(0) ack 187 win 16745 (DF) (ttl 128, id 11819, len 40)

10:44:15.710102 terserver.2302 > fdina.1249: F [tcp sum ok] 1:1(0) ack 933965 win 17520 (DF) (ttl 128, id 11841, len 40)

10:44:15.720265 fdina.1249 > terserver.2302: R [tcp sum ok] 916392225:916392225(0) win 0 (ttl 127, id 5004, len 40)

[fdina]

We could isolate the problem That lead us to some black-box switches we have. Only the machines connected to these switches have the problem. So the problem is not with the PIX firewall. These switches are cascaded to a Cisco Catalyst switch who in turns is connected to the inside interface on the PIX. If connect machines to the Catalyst we have no problems.

Thanks all for the help

Faustino