Celebrity Deathmatch: Access Policy Rules vs. Server Publishing Rules

We often get asked about the difference between access policy rules and server publishing rules.When should you use one in preference to the other?

Some of the differences (in no particular order) are:

[Trivial point #1] Access policy rules allow or deny traffic. Server publishing rules can only allow traffic.

[Trivial point #2] Access policy rules can allow traffic to multiple targets. Server publishing rules can only allow traffic to a single target.

[Trivial point #3] An access policy rule may allow several protocols. A server publishing rule can only publish a single protocol.

[Trivial point #4] A server publishing rule can publish services on a different port than the actual service port.

[Major point #5] Access policy rules allowing traffic from A to B work if the address relationship between A and B is ROUTE A/B or if it is NAT AàB. They won’t work if the address relationship is NAT BàA. Server publishing rules publishing a server in B to clients in A work if the address relationships is ROUTE A/B or if it is NAT BàA.

[Often overlooked point #6] Yes, you read that last point right: server publishing rules can operate when the address relationship is ROUTE. It works as you’d expect: the client connects to the server’s actual address (and not the publishing address on the ISA Server machine, although that might also work in some cases).

[Major point #7] The HTTP protocol is special. The web filter works with access policy rules as well as its own web publishing rules. Also, the web filter always acts as a proxy to HTTP requests even for clients that attempt to connect directly to the server and not as web proxy clients. Thus, the server never sees the address of the client itself, but the address of the firewall. It is as if the firewall always does address translation, even if the address relationship is ROUTE. (Note: web publishing rules are not the same as server publishing rules; for example, you can have deny web publishing rules.)

[Major point #8] If NLB integration is used, ISA Server ensures that clients connecting to a server published via a server publishing rules are load-balanced properly (according to the client’s address). If you use access policy rules, you don’t get this guarantee.

[Hidden point #9] Some application filters behave differently when the traffic is allowed through access policy rules vs. when it is allowed by server publishing rules. For example, the built-in SMTP filter only inspects SMTP traffic that is allowed by server publishing rules.

[Confusing point #10] Server publishing rules operate on protocols defined as “incoming” (for TCP), “receive” (UDP), or “receive send” (also UDP). Access policy rules operate on protocols defined as “outgoing” (TCP), “send” (UDP and RAW), or “send receive” (UDP and RAW).

[Confusing and little-known point #11] Access policy rules might, if the moon is under the right sign, also operate on protocols defined as “incoming”, “receive”, or “receive send”. This is done for legacy reasons, and support for this is likely to be dropped in future releases of ISA Server, so I won’t tell you how to do this :-)

[Minor point #12] Server publishing rules can do address translation in both directions, so that ISA hides both the address of the client from the server, and vice versa. (Internally, we refer to server publishing rules operating in this mode as “full proxy”.)

[Minor point #13] A nice variation of point #8 is that server publishing rules can actually allow a client in network A to access a server in the same network via a server publishing whose “listener” is on some other network B. Without this feature, you’d need to have a split DNS if you want clients in both network A and B to access the server (the server name resolves to the firewall’s address for clients in network B, but to the actual server’s address for clients in network A).

 

Hope you find this useful,

Ziv Caspi (2/3)

Comments

• Anonymous
  January 01, 2003
  Yes, the folks behind ISA Server have their own blog now. And have done for a month.  Go subscribe!...

• Anonymous
  January 01, 2003
  If no IP addresses are in the list and you want to prevent requests from IP address 127.0.9.1 from being routed, add 127.0.0.1 as an FQDN to the list.

• Anonymous
  January 16, 2006
  The comment has been removed

• Anonymous
  January 17, 2006
  More about this at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/internalclientaccess.mspx
  

• Anonymous
  January 17, 2006
  The comment has been removed

• Anonymous
  January 17, 2006
  The comment has been removed

• Anonymous
  January 17, 2006
  Just to clarify - the folks who consider the 'Denied by an Allow Rule' scenario a bug feel that if ISA can't verify a parameter (as in a rule allowing HTTP access for All Authenticated Users and Secure NAT clients getting blocked as a result of this), it should move on to the next rule.
  
  Furthermore, they feel the 'Default Deny' rule should be the only rule that denies access, short of admins creating Deny rules.

• Anonymous
  January 17, 2006
  Hi Clint,
  I recall mentioning this during the private beta in the newsgroups, and they were aware of the issue. I think it was recognized that this would create confusion, but it was too late to change the model. Maybe in an upcoming version anonymous connections will only match anonymous rules? --Tom