When using server publishing in a Route relationship, the server publishing rule works like an access rule to allow access to the published server. Clients send requests directly to the IP address of the server being published, and not to the IP address of the ISA Server client-facing network interface. So, what’s than the difference between an access rule and a server publishing rule in such a scenario?
You can find some useful information in the online help topic Access rules and server publishing rules. Additional, in the ISA Server Product Team Blog you can find an article Celebrity Deathmatch: Access Policy Rules vs. Server Publishing Rules containing a fantastic set of facts. We won’t repeat them here. Instead, we like to comment on two of them (Trivial point #4 and Minor point #12) because we’ve seen a slightly different functional behavior as from what might be understood out of that article.
Let’s first describe the following simple but very common scenario:
To show the different functional behavior between a server publishing rule in a Routed and a NATed scenario, we’ve published with the same rule an internal Telnet server (192.168.22.2) onto the ISA External (192.168.1.10) and Perimeter (192.168.33.1) interface. Take note we’ve configured a Route relationship between the Internal and the Perimeter network and a NAT relationship between the Internal and the External network. If we repeat the same server publishing tests but with an internal SMTP or FTP server, we see the exact same functional behavior.
With a standard Telnet Server server publishing rule we see the following relevant creation objects:
That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:0023 and from the Perimeter network with the destination socket 192.168.022.002:0023, both as expected.
Now, let’s look what happens if we modify the server publishing rule and play with the options Firewall Ports, Published Server Ports and Full Proxy mode.
[Trivial point #4] A server publishing rule can publish services on a different port than the actual service port.
Let’s first change the Firewall Ports and publish the internal Telnet server on the TCP port 2323. The relevant creation objects are than:
That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:2323 as expected. However, from the Perimeter network we have to access the internal Telnet server with the destination socket 192.168.022.002:0023.
Next, let’s restore the default Firewall Ports setting and change the Published Server Ports setting to TCP port 2323. Of course the internal Telnet server must now listen on TCP port 2323. The relevant creation objects are than:
That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:0023 as expected. However, from the Perimeter network we have to access the internal Telnet server with the destination socket 192.168.022.002:2323.
As a conclusion we can say that with a Route relationship you can *not* do any port redirection. In that aspect, a server publishing rule behaves exactly the same as an access rule.
[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”.).
Let’s first enable the Full Proxy mode by selecting Requests appears to come from the ISA Server computer in the To tab of the server publishing rule and apply the changes. Then we setup a Telnet connection from an Internet (192.168.1.100) and a Perimeter (192.168.33.10) host. Finally we check out on the Telnet server with the help of the netstat command from which IP address the telnet connections appears to come from. The result is shown below:
That means that the original IP address of the Internet host (192.168.1.100) has been translated by the ISA server to the primary IP address assigned to the ISA internal interface (192.168.22.1) as expected. However, the original IP address of the Perimeter host (192.168.33.10) is not translated at all.
As a conclusion we can say that with a Route relationship you can *not* do any address translation. In that aspect, a server publishing rule behaves exactly the same as an access rule.
HTH,
Stefaan