Mittens: lol. "Read the ****ing Whitepaper"




I went back and reread your first post, I am still looking for a link to a whitepaper though, you did post a link to itright, come to think of it, I didnt even see a mention of a whitepaper in your first post? or was your post the whitepaper? I suppose I should just go "google" for windows xp service pack 2 whitepaper right?
Use google, yes, or better yet the direct link to the white paper in my white paper subpost.

There is a problem with the current version of ICF, in that when enabled, it causes issues with Outlook and Exchange. The bottom line is, unless outlook initiates a conversation with exchange, the traffic from exchange is denied, therefore users get no notification that they have new mail, nor does any new mail appear in their inbox, unless the user takes some action which causes Outlook to make a request to exchange, such as, changing folders.
The current ICF is horrible, disgusting, and limited. The ICF before SP2 was an nightmare for all admins and usually disabled with a snicker. What you will like about ICF is it now controls outbound and inbound, instead of just inbound. This means you can configure a service, a port, a protocol, or even a program name to have access in and out according to the ruleset you define. Much better than the origonal ICF, and quite literally like how Zonealarm handles their rulesets. This means too that if an app is caught trying to access the net that is not defined in the ruleset, ICF will now alert you for permission or denial. SP2 makes the most changes and upgrades to the ICF, since they knew how much people like you and me hated the crippled version.

Problem is, from past experience, there are many times when Exchange initiates communication to the client, for example, when a user recieves new mail, also, from my current experience, the ports used by exchange to do communicate with outlook is a dynamic range, it is not always the same one, like for example, everyone knows that port 25 is smtp, with the communication between exchange and an outlook client there is no one port(although a number of your standard windows type ports are used for "controll" or initiation perposes) there are lots of different ports that could be used.
See above responce. Since we can define program name, protocol, and service it allows much more control. And since ICF now does inbound and finally outbound checking, The clients connecting to the exchange server, should be a peice of cake. In theory of course, this isn't the final release of SP2 so who knows. I am hopeful though

So, I guess after all that, my question is the same as it was before I went back to re-read your post.
It is. And I thank you for reading and coming back with a learning frame of mind. Before, things seemed rather "prove it!" than question/answer, so I am glad we can take a step back to explain and understand. My thanks for your patience.

Does the new version of ICF work properly with Outlook and Exchange? Does it recognize seemingly unrelated traffic(from a tcp/ip standpoint) as being legitimate traffic going from exchange to the outlook client?
See my above responces to you on ICF outbound and inbound control. In short, yes it does work properly (tested with outlook)

If it does not recognize that traffic, that means I have to create additional rules to specificaly allow that traffic, not a problem, been there before, but, I do not seem to see a of allowing a specific IP address to access the machine which has the firewall. I see, allow access to a port, from either everywhere, or local subnet. I do not want to allow all, to the machine, nor do I want to allow local subnet too the machine, I want to allow exchangeserver.example.com to the machine, or more properly 172.X.X.X. Allowing local subnet kind of defeats the purpose of this firewall in the first place(except maybe for laptops, as I said previously) because they are already protected quite well from the outside world, the point of using this firewall would be to prevent a worm or other internal danger from accessing this users machine, assuming that someone has managed to succesfully plug an infected laptop into our internal network.
Understandable, and even if the Exchange server goes a bit nuts (which it shouldn't, testing went perfect) you can fine tune that ruleset and even put them in a profile. This means people using laptops remotely could use the laptop profile (for different security settings) than the internal nodes would use.

Since I have now made an effort to educate myself and make "informed decisions", can you please please please answer the question.
I think I pretty much answered the question in the first part of my reply here, in regards to ICF now having outbound and inbound control, on much more fine tuned rulesets. However, if any questons remain, don't hesitate to ask