This is a discussion on RE: [fw-wiz] Strange Pix behavior. - Firewalls ; 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 ...
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
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
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.
PS - Your reseller sucks.
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
Sample log entry follows:
.... Deny tcp src outside:
/80 dst LAN: /31997 by
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