Transparent vs. Non-transparent AGs/SPFs/whatever

["Ryan Russell" <ryanr () sybase com>]

No, this is *that* holy war about SPFs vs AGs...

One of the great advantages (also vulnerability, read on) of packet
filter type and related firewalls is that they're transparent to the
clients.
That is, they require no changes to client software to function, and
the clients think they're connected to the raw Internet.

The firewall devices of this nature typically act like a router or
bridge, and you simply point your Internet bound traffic in
their direction.

One can also make Application Gateways transparent, too, I'm
told.  There is a transparency toolkit for the FWTK, I believe.

Obivously, there are also AGs that require the client to do something
different to get to the Internet.

The advantage to AGs is that they should be able to speak the
exact protocol being used, and hopefully keep some unanticipated
funny business from going on.

Non-transparent proxies can make clients tell them what protocol
they're trying to speak, as well as to whom, and on what port.  So,
policy permitting, I could request that the proxy let me talk
to someserver, with the telnet protocol, at port 2300 instead of
23.

If I've got a transparent proxy, or some SPF, how is it supposed to
know that when I connect to port 2300, I want the telnet protocol
instead of HTTP, FTP, or something else?

There are obviously some clues in the data stream as to what the
protocol is, but trying to figure it out on the fly won't scale very well.

Now, if I had gone through the transparent device, but to port 23,
it could (likely safely) assume telnet.

So here's my question:

If I want transparency, am I essentially stuck trying to
determine protocol strictly by port number?  If I want to permit
people out to arbitrary port numbers, am I stuck with the
equivalent of a circuit-level proxy?

                         Ryan