Teardown followed by two 'Deny' entries in PIX logs

Hi,

I'm seeing long delays transferring files via FTP. The connection is initiated from the external IP. I'm hoping for some insight into these PIX logs.

Internal address is x.x.x.x
External Address is y.y.y.y
Firewall interface is z.z.z.z

-Firstly, there's an inbound Build operation from the External address to Internal Address.
 3/27/2009 6:00      Friday      6:00 AM - 7:00 AM      z.z.z.z      Built      [message removed]      PIX-6-302013      PIX      6      302013      TCP      y.y.y.y      (empty) x.x.x.x       (empty)      (empty)      22      50559      outside      dmz      50559_tcp

-The connection is closed after 16 mins
27/Mar/2009 06:16:24       z.z.z.z       Teardown       [message removed]       PIX-6-302014       PIX       6       302014       TCP       x.x.x.x       (empty)       y.y.y.y      (empty)       (empty)       50559       22       dmz       outside       22_tcp  TCP Reset-I       

-Then I see two identical DENYs from x.x.x.x to y.y.y.y (same timestamp as the TEARDOWN)
27/Mar/2009 06:16:24       z.z.z.z       Deny       [message removed]       PIX-6-106015       PIX       6       106015       TCP       x.x.x.x       (empty)       y.y.y.y       (empty)       (empty)       50559       22       (empty)       (empty)       22_tcp  RST
27/Mar/2009 06:16:24       z.z.z.z       Deny       [message removed]       PIX-6-106015       PIX       6       106015       TCP       x.x.x.x       (empty)       y.y.y.y       (empty)       (empty)       50559       22       (empty)       (empty)       22_tcp  RST

Is this normal operation? Or is the connection being reset before the FTP transfer has completed?
Thanks,
John
LVL 2
sherryfitzgroupAsked:
Who is Participating?
 
JFrederick29Commented:
By default the Firewall won't tear down a TCP connection unless it is idle for 60 minutes so the Firewall isn't tearing the connection down after 16 minutes before the FTP transfer completes.  The server closed the connection by sending 3 TCP RST's.  The Firewall received the first RST in which it will immediately tears down the connection.   The connection is now torn down and so the other two RST's from the server result in the last two messages (Deny no connection).  This is normal operation.  The Firewall is simply responding to what it is seeing from the servers.
0
 
sherryfitzgroupAuthor Commented:
THanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.