The sequence number in syn/push/ack response to syn is good.

There is no ack response to syn/push/ack. This packet is never passed thru the FWSM to the syn originator, so no ack from the connection requestor.

I did not see anything on Linksys web site either.

Assuming the PUSH flag is the problem (and I think this is probable) is there any way to circumvent the incorrect implementation of Linksys by the FWSM (i.e., turn off FLAG BIT validation)?

(My guess is that the PIX/FWSM is quietly dropping all packets with invalid flag bit combinations to thwart reconnaissance efforts by programs like NMAP which do machine software determination by examining responses to invalid flag bit combinations.)

The sequence number in syn/push/ack response to syn is good.

There is no ack response to syn/push/ack. This packet is never passed thru the FWSM to the syn originator, so no ack from the connection requestor.

I did not see anything on Linksys web site either.

Assuming the PUSH flag is the problem (and I think this is probable) is there any way to circumvent the incorrect implementation of Linksys by the FWSM (i.e., turn off FLAG BIT validation)?

(My guess is that the PIX/FWSM is quietly dropping all packets with invalid flag bit combinations to thwart reconnaissance efforts by programs like NMAP which do machine software determination by examining responses to invalid flag bit combinations.)

When you ran your line/packet trace, did you also trace between the lpr/client host and the fwsm? I assume that your first trace was between the linksys and the fwsm, but I am interested if the 2nd trace would show the same results - if it does then the fwsm is sending the packet to the lpr/client, and we need to see if that host responds.

One other thing to look at is if NAT/PAT is used for the client. Are you using nat/global or static?

The FWSM is set to do no address translation. Actually we have both NAT 0 and Static. We have no problems going to other TCP services thru the FWSM.

Yes, I did trace on both sides of the FWSM.

A = lpr client, B = lpd service

"A" is on the Inside interface, "B" is on the outside.

Intial flow is SYN from A to B. Seen on both sides of the FWSM.

Next flow is SYN/PUSH/ACK from B to A - seen only on the outside of the FWSM.

Since "A" never sees this, no final-handshake ACK is sent from A to B.

"B" eventually retransmits the SYN/PUSH/ACK.

Eventually "A" tries the SYN again. Then the above repeats.

What version of FWSM code are you running? I can check the cco bug list to see if this is a known problem with your code; if you have a cco account you can do the same.

FWSM is at 1.1(3)

Hey guys...I responded to this post on Wednesday during the time when we announced the TCP vulnerabilities but I guess the site was too busy to process the post. Sorry about that.

Anyway, this is a Linksys issue and not an issue with the FWSM. We are not going to allow any data to pass (PSH) unitl the TCP socket has been setup (three way handshake complete). The FWSM is silently dropping these packets as a result. I would suggest taking this up with the Linksys support folks. If you have a trace of this, I am sure they would like to see it (if they don't know about the issue already).

Hope this helps.

Scott

Thanks for the response.

My interpretation of RFC793 is consistant with what you have said: That PUSH is an application function and is not valid until the session is fully established.

Part of the query was to see if anyone else had this problem. Another part was to find out if there was some way (at least temporarily) to negate the default action by the PIX/FWSM, which I agree is the prudent thing to do.

So far, I have not had any response personally in working with Linksys on this. The customer who actually owns the units actually has had a telephone dialogue with them, but I don't know the outcome of that discussion.