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