Re: Direction paradigm? n00b question

Tech-Archive recommends: Fix windows errors by optimizing your registry

First, thank you for your reply, Phillip.

Please excuse my ignorance; this server product is not my area of
expertise; I specialize in *nix anti-spam solutions with Exchange
integration. I got into a bunch of unnecessary rebuttal below, but the
main questions are: what is the point of view/perspective/reference
point from which "inbound" and "outbound" are determined? Is it the
ISA machine, (i.e., inbound="initial connection from client (from
wherever) asking for connection on x port" and outbound="traffic
originating from ISA machine directed at x port on remote machine")?
Is it the Protected Networks (i.e., inbound="traffic directed at ISA
from an unprotected network" and outbound="traffic originating in a
protected network")? Is it a third option? Understanding this point
of reference may help me understand why, for instance, the SBS SMTP
Server Access Rule uses an "outbound" protocol definition but the
source is "external" and destination is "localhost"; that sound like
"inbound" traffic to me. But, if you create a mail server publishing
rule (for server-to-server comm), that uses the (expected) inbound
protocol for port 25 and specifies the published server. Are both
rules needed (esp. the SMTP Server Access Rule)? Can you help me with
that conceptually? For instance, does one classify traffic directed at
the ISA/SBS machine from LAN computers to be inbound or outbound?

If I want to allow LDAP queries from a Linux machine on the LAN, what
would the rule be? Is that considered inbound or outbound? Should
that be a server publishing rule or access rule?

</main questions>

I've seen most of the available documentation that's online (and
usually find myself frustrated with books which usually take too long
to get to the point); that's why I'm asking in this group.

I have used packet filters a bunch in ISA 2000, and, on SBS 2000 for
instance, a bunch are created by default. They even have their own
little container under Access Policy, called IP Packet Filters. If
that was "wrong", then I regret that, but so should the annoying
"Connect to the Internet" wizard in SBS.

Phillip Windell wrote:

Stay away from the System Policy. As long as the machine was a Domain
Member before the ISA was installed those are already correct and would
pretty much never be touched.

Fair enough.

In ISA 2k, packet filter rules made sense to me. They were based on a
very simple filter definition that specified IP protocol type, local
and remote port numbers (with options for dynamic or all port numbers)
and the direction of intial traffic *relative to the ISA server*.

What you describe weren't the packet filters. Those were the Protocol
Definitions.

No, I'm describing an ISA 2000 IP packet filter with custom filter (not
predefined); protocol definitions were a simple, port number, direction
thing which I used almost exclusively to allow outbound traffic on
unusual ports from Secure NAT clients.

You never used "packet filters" in the first place even with the older one.
If you did you were using it wrong.

If one is trying to open a port for
traffic incoming to the ISA (from local LAN or external nets), is the

You don't "open ports". Never did. All the way back to the old MS Proxy
Server you never "opened ports".

If I only want initial inbound connections to a particular port from an
expected client port (and no others), it would make sense to specify
the client port. I didn't expect that would destroy the stateful
inspection of the resulting traffic, but I'd not be upset to be wrong.

Outbound Traffic
Controlled by Access Rules. Access Rules are *outbound only*.

Inbound Traffic
Controlled by Publishing Rules. There is more than one type of
Publishing Rule.
Publishing Rules are *inbound only*.

Sources, Destinations, IP Ranges, Protocols, Networks, Users, Computers,
Groups of Computers are all *Object Oriented*. You create an Object that
represents the entity, then you use the Object in the Rules.

The links in my signature may be usefull.

--
Phillip Windell [MCP, MVP, CCNA]

.

Quantcast