ISA 2000 isn’t out-of-the-box able to change published ports when doing Server Publishing. (I think Application Filters can be written to do this, but I’m not totally sure). ISA 2004 can do this.
RRAS has had the ability to translate a port mapping from a certain external port to a different internal port for a while – I’ve used it in Windows 2000 and Windows 2003 (avec Basic Firewall). This is sometimes called Port Address Translation, or PAT, and can essentially be thought of as a special case of NAT; instead of (or rather, as well as) translating the IP address, the port information in the TCP/UDP header is hacked and a mapping is maintained.
For example: you want to publish a Terminal Server (or Remote Desktop) on your external IP, port 3100, and translate this to an internal IP, port 3389. Using RRAS, this is done fairly quickly.
With ISA 2000, you’d need to actually change the internal port as well, so TS on the internal box would need to be hacked to run on port 3100 too. The capability to change the source or destination port when Server Publishing is not available. The protocol definition is the port, and the port shall be used, and only the port in the protocol definition shall be used.
With Web Publishing, you can do whatever you like with the internal ports, but it only applies to Web Proxy-handled traffic, which doesn’t include Terminal Server (RDP) or other straight-IP-based protocols (only HTTP/SSL), and will be stuck listening on whatever port you’ve configured your Incoming Web Listener for. So not helpful here.
Additionally, you typically need to create a separate protocol definition per individual port used. So, not great for publishing non-load-balanced groups of servers.
My take on this is that it’s actually a mixed blessing. If a port is open externally, you know immediately which internal port it’s going to be published on, with no mess, no fuss, no guesswork. If it looks like you’re server publishing an NNTP feed, you can be reliably assured that someone is publishing an NNTP feed.
Also useful to keep in mind – RRAS doesn’t provide any kind of inspection for any traffic, so you’re essentially punching holes to internal clients. With RDP, there’s little distinction because it’s encrypted and can’t really be inspected in realtime, but for protocols like HTTP, unless you’re also securing your back-end server, you potentially lose a layer of inspection.
ISA 2004 (Beta) has port hacking capabilities which are configurable when you publish a server, so the above scenario is do-able.