Yeah, I ran into the same type of issue where SYN packets going through a Cisco FWSM Firewall module in our Catalyst switches were being changed. The FWSM code was randomizing the "Acknowledgement Number" (not ACK bit) field similarily to the "Sequence Number" randomization and IP Filter was marking the packets as BAD (FI_BAD in the source code).
I reported this to Cisco as an issue and asked them why they were randomizing it on egress from the FWSM when the "Ack Num" field left the station as a 0 and they couldn't come up with a reasonable explanation so they filed a bug reluctantly - stating incompatability with "Personal Firewalls" (that pissed me off). Anyway, Darren changed the code in the distribution as a work around to fix this interopability problem which you can see in the comments of the program. The problem I encountered was fixed by Cisco on their side in the FWSM code as of code 2.2.(1.14) or 2.3(0.27) [CSCef11642 Bug] IP Filter hasn't been reverted yet with a comment to indicate if you are having problems to comment the line out below; but I know what to fix when I upgrade IP Filter at some point. I haven't tested this out in a lab to see if it works but Cisco is pretty good at this type of thing when they recognize and fix them. Your problem is not related to a Cisco platform but I thought it might be a bit insightful as to same type of marking of packets as BAD. I too would like to know if there is some sort of standard that is being used to determine BAD packets or not.... Just more security concious design in light of vague RFC standards? In the case of my problem encountered; either interpretation (IPF or FWSM) could be viewed as "right" - nothing stating that the 'ack num' field couldn't be changed; but at the same time what purpose was there for this as there doesn't appear to be any security related reason behind it because it was the first packet and no packets should have been acknowledged at this point. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Chard Sent: Tuesday, March 22, 2005 7:01 AM To: [email protected] Subject: SYN+PUSH packets from ancient device getting dropped by ipfilter Hi, I recently moved our library catalogue service to a new server running ipfilter 4.1.3 on Solaris 9, and old PCs used as dedicated catalogue terminals stopped working. After some investigation I found that these machines (running DOS) set the PUSH flag on their initial SYN packet, which ipfilter drops when "keep state" is specified. The code that does this in in fil.c, around line 943 (and seems to still be there in ipfilter 4.1.7). I was able to work around the problem by removing "keep state". Is there a standards-based reason why ipfilter marks such packets as bad, or is it just that they are almost never seen? I can see that it makes no sense to set PUSH in a SYN packet, but I just wanted to know if the old PCs are violating some standard or if this is a design decision of ipfilter. Thanks - Ian -- Ian Chard, Unix & Network Administrator | E: [EMAIL PROTECTED] Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 204937
