1, the computer has no brain. So, when ISA behaves inconsistently with your requirements, check your configuration and don't blame Isa.
2. Allow only the customers, source addresses, destinations, and agreements you want to allow. Check each of your rules carefully to see if the elements of the rule are consistent with what you need, and try to avoid using rejection rules.
3. For the same user or an access rule with a subset of the same user, the rejected rules must precede the allowed rules.
4. Explicit rejection is the primary consideration when you need to use rejection.
5. If you do not affect the effect of firewall policy execution, put the higher matching rules in front.
6. If you do not affect the effect of firewall policy execution, put the rules for all users in front.
7. To simplify your rules as much as possible, the efficiency of executing a rule is always more efficient than executing two rules.
8. Never use the Allow 4 all rule in a commercial network (allow all users using all protocols from all networks to all networks), which simply makes your Isa-shaped dummy.
9, if you can configure the system policy to implement, there is no need to establish a custom rule.
10. Each access rule for ISA is independent and is not affected by other access rules when each access rule is executed.
11. Never allow any network access to all of the ISA native protocols. The internal network is also untrustworthy.
12. Snat Customer cannot submit authentication information. So, when you use authentication, configure the customer as a Web proxy client or Firewall client.
13. It is best to use an IP address, regardless of the purpose or source of the access rule.
14. If you must use a domain name set or a URL set in an access rule, it is a good idea to configure the customer as a Web proxy customer.
15, please do not forget, the firewall policy finally there is a deny 4 all.
16. Finally, keep in mind that testing of firewall policies is required.
16 rules for deploying Windows ISA Firewall Policy
