Being kind of a rookie to ISA Server 2004, my goal is to develop a "strategy" of how I am going to deal with traffic (ports & protocols) which I have no Access RUle developed for.
FIRST, a bit of history. Currently, my servers use SecureNAT to go out through a non-ISA firewall. All this is about to change when I place ISA Server 2004 on my network. All outgoing Internet traffic from these servers will go through the ISA firewall instead of my hardware firewall.
AND LAST, not knowing all of the possibilites of protocols and ports going through my existing firewall, I am seeking a sure-fire way of determining what Access Rules that I need to create BASED UPON some kind of "intelligence" from ISA 2004.
What is everyone else doing about this issue when their server's default gateway's are now running through ISA? I've read of person's who run in to a mountain of problems post-install because of this issue.
Your clients don't have to change their style of access, you can use SecureNAT, Web Proxy or Firewall Clients depending on the OS or setup you have those clients in. If you can, setup firewall clients on your boxes, this - with extra tick box checking - will also setup up your clients web proxy settings. And finally if you can't setup web proxy clients then SecureNAT is your final option.
Depending on your ability to 'test' your setup, ISA's logging is great. It'll report to you all the traffic thats being denied by the box using the logging tab in monitoring. This is only going to give you info if you can drop the box into it's live environment for an amount of time for it to pick up enough information for you to create a ruleset from the results. Alternatively create a situation where your 'test' ISA box has some boxes with the apps your running sitting behind it and let them start requesting data. Again the logs will fill up and you'll be able to see the ports/protocols that are requested and denied.
That or port mirroring on a Cisco switch with ISA to log all the traffic that ends up at your gateway or Etherreal(very very dull way of looking at your traffic unless you wish to see the explicit details of each packet coming in) I reckon thats it. Anyone else got any ideas?