Problem with PIX (FWSM) and LPR to Linksys WPS11 connecting

Unanswered Question
Apr 20th, 2004
User Badges:

We imposed a PIX (actually FWSM) between an LPR host and a Linksys WPS11 LPD print server. TCP connections (incudline LPR/LPD, WEB management, and Telnet management) to the Linksys no longer succeed across the firewall.


A trace of the connection attempt show a SYN/PUSH/ACK from the Linksys rather than a SYN/ACK in response to the SYN request.


We suspect the FWSM is rejecting this because of invalid FLAG bits in the TCP header, but nothing is logged at informational logging level.


Am I correct that the PUSH bit is causing the failure to connect?


Is there a way to turn off FLAG bit validation in the FWSM at least temporarily?


Is there a Linksys fix for this?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
ehirsel Wed, 04/21/2004 - 03:41
User Badges:
  • Silver, 250 points or more

Did you see the ack coming back from the fwsm?


Check the ack value from the linksys, it should match the syn seq value + 1.


I've queried the KB at www.linksys.com but I could not find any matches for your problem.


These are the only thoughts that I have for now.


jerry.marsh Wed, 04/21/2004 - 05:29
User Badges:

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.)

jerry.marsh Wed, 04/21/2004 - 05:31
User Badges:

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.)

ehirsel Wed, 04/21/2004 - 06:00
User Badges:
  • Silver, 250 points or more

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?



jerry.marsh Wed, 04/21/2004 - 13:36
User Badges:

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.


ehirsel Thu, 04/22/2004 - 20:07
User Badges:
  • Silver, 250 points or more

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.



scoclayton Fri, 04/23/2004 - 12:08
User Badges:
  • Gold, 750 points or more

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

jerry.marsh Fri, 04/23/2004 - 12:40
User Badges:

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.

Actions

This Discussion