We were updating a Lenovo laptop - wow, they sure have a lot of software updates for their laptops - and when it rebooted, it could no longer connect to the network.
After some troubleshooting, it turned out that it looked like the physical connection was dead.
Nope, take it to another network connection and still the same thing.
The bad thing was, it was one partner in the firm, and when the other partner decided to take his Lenovo out of its docking station and plug in the troublesome one, he could no longer connect!
I ended up heading in to verify just what was going on as a remote session could only get me so far.
I took a new network switch with me just in case. Plug all the active nodes in, and nope, problem still existed, only now everyone couldn't connect even after a reboot of their systems.
I remembered dealing with this before, and low and behold I found my culprit:
Whenever a network connection is released, you see 0.0.0.0 when the "IP" comes up via ipconfig /release. If you try and renew your address, and no DHCP server answers, then you end up with a 169.x.x.x IP. However, when the machine calls out to the DHCP server, it still broadcasts itself from 0.0.0.0.
Guess what? ISA says, "No way & no how are you coming in here!"
I belive that most of us do not encounter this situation often, because the network adapter tends to hold on to the address it had until it expires, then ask for another one, FROM the now expired address. And so on, and so on...
So, here is the fix:
Or should I say, the fix that I came up with in a pinch! :D It works though, and that is the main thing.
Take careful note when creating the Access Rule, that I have both DHCP services, both Internal and Local Host included in the From part of the rule, and All Protected Networks (including Local Host) in the To part of the rule!
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
4 comments:
Interesting.. we have seen a somewhat similar problem on 2 SBS systems now.. doesn't seem like anyone else out there is getting it:
http://www.smbus.org.nz/index.php?id=22
Andrew,
I have seen it off and on since the implemtation of ISA 2004 as part of SP 1 on SBS.
The rule creation eliminates the problem immediately.
It is something that we do now by default on all SP1 and R2 SBS builds.
Thanks,
Philip
Hi Philip,
Thanks for your comments. The problem I am seeing is actually slightly different. The Vista machines report themselves as a 169.x.x.x address (even after releasing the IP address) when they make the DHCP broadcast. This is what ISA doesn't like as it considers 169.x.x.x addresses to be external. Our fix is to make 169.x.x.x part of the LAT and also to put a 169.x.x.x additional IP address on the internal NIC of the server.
We also put the rule that you do on to most of our SBS builds.
Cheers,
Andrew
I disagree with the methodology.
By setting up the 169.x.x.x a huge hole has been opened into the server, especially by including it in the LAT and allowing it through ISA.
In my mind, the best method would be to create an IP Client set in ISA with the 169.x.x.x in it and create a rule allowing the DHCP Q/A on that IP Client set.
This way only DHCP traffic will be allowed through on that IP range.
Philip
Post a Comment