[Today’s post comes to us courtesy of Justin Crosby]
Today we are going to discuss a somewhat common issue caused by an ISA misconfiguration: Clients not getting DHCP addresses from their SBS 2003 server running ISA 2004. On a default install of SBS 2003 with ISA 2004 where the CEICW has been run this issue WILL NOT occur. The CEICW configures the necessary rules to allow clients to access DHCP. This issue is only seen when users start adding custom ISA rules and make a mistake. This blog post will show you how to avoid these mistakes.
The most common mistake is to incorrectly configure the Internal network address range. This range is used by ISA to determine what network the IP address belongs to. If your address range does not include the broadcast address ISA will treat your clients DHCP traffic as spoofed. By default SBS uses the 192.168.16.x range for the internal network. When you use this subnet the range you enter into ISA will be 192.168.16.0 – 192.168.16.255. It is essential to include the .0 and .255. To access the address ranges:
- Open ISA Server Management.
- Expand your ServerName
- Expand Configuration
- Select Networks
- Select the Networks tab
- Double-click the Internal network
- Select the Addesses tab
- Verify you have your entire IP range defined.
Here are two example ranges, one using a class A subnet and one using a class C. We recommend clients avoid using CIDR (variable-length subnet masking) on their private network to keep things simple.
|Address||Subnet Mask||Range Start||Range End|
The other common misconfiguration that will break DHCP client addressing is a mistake in rule logic. The most common errors in rule logic are:
- DHCP traffic is not authenticated traffic, therefore the rule that allows DHCP traffic from your clients to your server must exist above any rules that require authentication. To tell if a rule requires authentication check the Users tab of the rule. If you see a user or group name, instead of “All Users” this rule requires authentication.
- DHCP traffic uses broadcast addresses which cannot be resolved to a URL. If you have a rule that blocks access to certain URLs above the rule that allows DHCP, ISA will block DHCP. This is because ISA will try to resolve the broadcast IP to a URL to make sure it is not blocked. Since the IP cannot be resolved ISA will block the traffic. The fix is to move the rule that allows DHCP traffic above any rules that block URL sets.
On SBS 2003 the CEICW creates a rule called SBS Protected Networks Access Rule. This is rule that allows DHCP traffic from clients to the server, and a lot more. To test if your issue may be a rule logic issue you can move this rule (SBS Protected Networks Access Rule) to order number 1. If this resolves your issue you know that one of your custom rules was blocking DHCP.
The final DHCP client issue that we will discuss today is not a configuration issue, but more of a clean-up issue. If your client cannot obtain an IP address is will fail back to an APIPA address in the 169.254.x.x subnet. This can happen if DHCP was broken when the client tried to renew it’s address; after you fix ISA you will need to fix this client. ISA does not consider the APIPA range to be a part of your Internal network, therefore if ISA sees traffic from an IP in this range on the internal network adapter it will drop it as a spoofed packet. This prevents clients who have an APIPA address from using DHCP. The easiest way to fix this is to do an IPCONFIG /RELEASE before running your IPCONFIG /RENEW. The /RELEASE will set the client’s IP to 0.0.0.0 which ISA will not treat as a spoofed packet.