allowing psh ack trough PIX

[rrvanderveen]

Hi,

Were experiencing a problem with print-traffic trough our PIX.

After sniffing we noticed that the print-traffic actually consist of not a normal tcp-3 way handshake but a "syn synack pshack" conversation, which is not allowed by the pix. After talking to the manufacturer of the printer they told us it was RFC 793 compliant, which it apparently is.

(This kind of handshake is usually called T/TCP which stands for "TCP for Transactions" and is

defined in RFC 1644.)

Our problem remains however. Has anyone got any experience with this and/or know a solution?

We can't find any solutions on forums or on the Cisco site, google etc.

Thanks in advance!

[ehirsel]

I just read some of the rfc 1644 specs, and found that it was written in 1994. I am not aware of any updates to it since then, so it may not have kept pace with stateful firewall technology, or it wasn't deployed with enough popularity for the firewalls to integrate with it.

One solution I can think of, to bypass the pix filtering, is to run the print stream via a IPSec vpn, where one tunnel gateway is inside the pix, and one outside.

Other than the printer, what other hosts are involved, and where are they in relation to the pix?

I would think that if IP/Print or BIP was used, the os on the client would have issues with the 3-way tcp not working properly.

Other solutions would be to see if it is possible to convert the print to using the unix lpr/lpd protocol, using udp, or some other standard using a more common ip protocols. See if one of them is possible.

Please post what you find.

[rrvanderveen]

Thanks for the advice,

as a matter of fact I yesterday found an article on how to set up acl's for tcp flag filtering on IOS 12.3.4 something. Basically means you can make an access-list to use as a selectionfilter for what kind of flags you will or will not allow.

Pretty cool and an equivalent command on the pix would solve our problem. But guess what... the pix doesn't know about that. Well, maybe later releases..

Anyway, I also read some more threads in which they have a similar problem and also advice to use ipsec

so maybe we will. Right now were looking to perhaps use another printing utility. At the moment the customer is using rlp-printing utility from a HP-UX platform (located on one side of the pix) and is trying to print to printers located on the other side of the pix. We made a rule to allow tcp 9100, which is the port the HP Jet-direct listens to.

The HP-UX platform whas migrated a couple a days ago from the same zone the printers are in, to a different zone on the pix. Prior to the migration, printing was no problem but since the pix refuses anything else then the default handshake, were stuck with three options

1) migrate the server back (little chance)

2) use ipsec

3) use different print-utility

Thanks again for your help,

Radboud Veld

Network administrator

[ehirsel]

Out of curiousity, what version of microcode is running on the Printer, and what make/model is the used for the printer lan attachment (i.e., external or internal nic).

At my org, we use Lexmark printers, but they run in HP JetDirect compat mode, and port 9100 is used, but I do not recall not seeing the 3-way tcp handshake between them and a Novell server running the Novell print gateway code.

[rrvanderveen]

Sorry for the late response, I went on a last-minute holiday since I'm shifting jobs.

I'm here on my last day but heard they'd apparantly managed to overcome the problem by redirecting the printing traffic to a different Unix platform (the handshake with psh was initialized on the HP-UX platform) so the printer itself didn't have anything to do with it except that it apparantly accepts these kind of handshakes (which in itself seems logical, being it rfc-compliant)

The pix ofcourse is a bit more security conscious

thanx anyway for your efforts

Radboud Veld