Firewall Wizards mailing list archives
RE: Strange Pix behavior.
From: "Paul Melson" <psmelson () comcast net>
Date: Mon, 13 Jun 2005 12:48:29 -0400
This is the typical behavior of most stateful firewalls expressed through log entries. What you're actually seeing is the firewall dropping the RST+ACK packet coming back from the remote web server at the end of the connection. A stateful TCP session works something like this: 1. SYN packet leaves client and is picked up by firewall. 2. Packet src/dst addresses and ports compared to directional access-list. 3. Upon matching a 'permit' access-list, a state entry is created that acts like an implicit access-list for the corresponding return traffic. (This works by mapping information from the accepted packet to the new "state table entry" access-list, like so: inbound_if <-> outbound_if dst_addr -> src_addr dst_port -> src_port src_addr_after_nat -> dst_addr src_port_after_nat -> dst_port 4. Firewall counts packets and watches for RST packet from either src or dst to know when the connection has ended. 5. When the RST is seen, the state table entry from #3 is deleted and the process begins again. If the firewall successfully deletes the state table entry before the remote server can send an RST+ACK (which is what you want, you don't want your firewall waiting for an untrusted system's predicted response before it revokes its access), that packet will be compared to the access-lists that allow traffic from the outside and if no match is found, it will be dropped and logged. Your firewall is working just fine, or at least, it's working as it was designed to work. If you don't want to see it, I recommend using Kiwi or syslog-ng to remove these entries from the syslog stream before they reach your log analyzer. PaulM PS - Your reseller sucks. -----Original Message----- Subject: [fw-wiz] Strange Pix behavior. We are using a pair of failover Pix 515s, and are consistently seeing denied return traffic that theoretically should have been allowed. Three zones are defined: LAN, DMZ and WAN and the policy is default deny. For the allowed outbound protocols like http, we are seeing (on weekdays) anywhere between 25,000 and 45,000 denials originating from web server addresses on the Internet port 80 to the NAT'ed IP address of LAN users. This is the return traffic in response to requests that originated from the LAN. Sample log entry follows: ... Deny tcp src outside:<www-server-IP>/80 dst LAN:<NAT-IP>/31997 by access-group "WAN" The corresponding rule in the LAN access-group is: access-list LAN permit tcp host X.X.X.X gt 1023 any eq www Not all traffic is blocked, only part of it, seemingly at random, otherwise no one would have been able to surf the web, which is not the case. We are also seeing denials generated by the return traffic of other allowed outbound protocols such as pop3, imap4, smtp and dns (udp); in numbers that seem to be proportional to the overall number of requests for each protocol. On week-ends when the traffic is very low, we are still seeing denials, in numbers proportional to overall requests. We have monitored CPU and memory utilization on the Pix, they are low (CPU < 10% and memory < 25%). The Cisco reseller has not come through with a credible explanation for this behavior or made suggestions on course of action for diagnosing the problem. Can anyone on this list help? _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Strange Pix behavior. George J. Jahchan, Eng. (Jun 10)
- Re: Strange Pix behavior. Victor Williams (Jun 10)
- RE: Strange Pix behavior. Paul Melson (Jun 15)
- Re: Strange Pix behavior. Jim MacLeod (Jun 17)
- RE: Strange Pix behavior. Paul Melson (Jun 17)
- Re: Strange Pix behavior. Martin Mačok (Jun 18)
- Re: Strange Pix behavior. Jim MacLeod (Jun 17)
- <Possible follow-ups>
- Re: Strange Pix behavior. LazloCarreidas (Jun 13)
- Re: Strange Pix behavior. Jim MacLeod (Jun 17)
- RE: Strange Pix behavior. Paul Melson (Jun 17)