[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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.