Re: [IPFilter] Cisco FWSM issue wrt TCP SYN/ACK sanity check

Hi Dareen,

Cisco came back with a bug fix for this problem from a few months ago. We
haven't test this in the lab yet but Cisco is pretty good with making their
fixes with this stuff.

Perhaps you could reenable the section of code that you have under revision
control in the general distribution and change the comments and associated
README files / documentation.

That is put in an blurb that indicates that if you have a problem with IP
Filter and the Cisco PIX (Packet Internet eXchange) or Catalyst FWSM
(FireWall Switch Module) equipment that you comment out the lines if you
have Cisco FWSM code prior to 2.2.(1.14) or 2.3(0.27) or leave it as is if
you have a newer code.


Brian

================================================== ======
CSCef11642 Bug Details


Headline FWSM inserts ACK number in Inbound SYN packet
Product c6k-fwm Model
Component fastpath Duplicate of
Severity 3 Severity help
StatusResolved Status help
First Found-in Version 2.2(1), 1.1(3)
First Fixed-in Version 2.2(1.14), 2.3(0.27) Version help
Release Notes

DESCRIPTION:
The FWSM is changing the ACK number from zero to a non-zero value on
Inbound SYN packet that traverse the Firewall Module. The ACK bit is
not being set, just the ACK value is being populated. This is causing
some Personal Firewall applications to drop the SYN packet.


WORKAROUND:
None.
================================================== ======







----- Original Message -----
From: "Darren Reed" <darrenr@reed.wattle.id.au>
To: <jamesm@allstream.net>
Cc: <ipfilter@coombs.anu.edu.au>; <brian.olmsted@allstream.com>
Sent: Sunday, June 20, 2004 8:36 PM
Subject: Re: [IPFilter] Cisco FWSM issue wrt TCP SYN/ACK sanity check


> In some email I received from James MacDonald, sie wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> We just recieved a note from Cisco stating that they have spoken to the
>> developers (of PIX/FWSM software) and that there is definitely no reason
>> that they should be randomizing the Acknowledgement Number in this way.
>> The developer as asked the TAC engineer to open a Cisco Bug report on
>> the issue. They said it will be months before we see a fix for this bug
>> though ... in the meantime, as I originally asked ... is there a chance
>> we can see a switch put into IPFilter that will ignore this check? This
>> would be a good enough work around for us while we wait for Cisco to
>> update PIX code ...
>
> I think until Cisco have a patch available, the best thing to do (in view
> of better interoperability) is to just make this check not have any
> adverse
> side effect.
>
> Darren
>
> Index: fil.c
> ================================================== =================
> RCS file: /devel/CVS/IP-Filter/fil.c,v
> retrieving revision 2.243.2.22
> diff -c -r2.243.2.22 fil.c
> *** fil.c 2004/06/17 02:05:37 2.243.2.22
> --- fil.c 2004/06/21 00:36:15
> ***************
> *** 930,936 ****
> * that to indicate a bad TCP packet.
> */
> if ((flags == TH_SYN) && (tcp->th_ack != 0)) {
> ! fin->fin_flx |= FI_BAD;
> } else if (!(flags & (TH_RST|TH_SYN))) {
> fin->fin_flx |= FI_BAD;
> } else if ((flags & (TH_URG|TH_PUSH|TH_FIN)) != 0) {
> --- 930,943 ----
> * that to indicate a bad TCP packet.
> */
> if ((flags == TH_SYN) && (tcp->th_ack != 0)) {
> ! /*
> ! * Cisco PIX sets the ACK field to a random value.
> ! * In light of this, do not set FI_BAD until a patch
> ! * is available from Cisco to ensure that
> ! * interoperability between existing systems is
> ! * achieved.
> ! */
> ! /*fin->fin_flx |= FI_BAD*/;
> } else if (!(flags & (TH_RST|TH_SYN))) {
> fin->fin_flx |= FI_BAD;
> } else if ((flags & (TH_URG|TH_PUSH|TH_FIN)) != 0) {