Strange Windows behavior on DHCP - cured by manual address - but not a good cure
-
Have had new pfSense box up and running for a bit more than a day now
Yes, I did search. Not that searching and finding what you are looking for always go together. I've been beating on *nix boxes since the 3B2 and Decunix, and it fails to make me a guru for anything I don't do often enough to recall where the tricks hide, much less when windows is added to the mix…
A fairly normal setup - dynamic WAN, internal LAN private NAT. DNS relay, DHCP server, squid, snort (still in "report-ony" mode.)
2.0.2 RELEASE pfsense,
2.9.2.3 pkg v. 2.5.4 snort
2.7.9 pkg v.4.3.3 squid
1.8.2 pkg v.2.32 lightsquid (room for improvement there, but that's another subject.)Oodles of machine/memory/disk.
Had (still have, really, just got a kludge-around for now) a strange problem with a DHCP Windows (7) machine. These machines are all on the LAN. It was connecting to the outside world fine. It could see the other other hosts in its workgroup (yes, workgroup, active directory has never been implemented here and I'm not itching to.) It could connect to filesharing on the Windows server that is also the WINS server. It could not connect to the SQL database hosted on that same machine, and it could not connect to the MacOS X fileserver, though it could see it. All three machines and the pfSense DHCP have the proper WINS server configured.
This worked fine on DHCP as provided by a netgear router, the most recent predecessor to the pfSense install. As it turns out after a day of trying to puzzle out what the heck its problem was, it also works fine if a hard-coded address is provided to the machine. Put it back on (pfsense) DHCP, and it breaks like clockwork, even with exactly the same address reserved for it on DHCP or hard-coded into it.
The only difference I can see between the two is that when it gets an address by DHCP from the pfSense, it also gets a domain handed to it, though it's only an internal fake domain (localdomain by default.) I'm not clear if pfSense will break if I try to leave that field blank, nor am I clear that it's actually the problem. But it's the only difference I can see between the two methods (or three) - ie, pfSense DHCP does that, netgear DHCP did not as far as I recall, and manually typing in an address does not. I'm not too convinced that "fake" FQDNs are an improvement over none on NAT, and it's been a long time since I had the luxury of enough real addresses for a network.
The servers' addresses are hardcoded.
Connecting to the outside world (web, email etc.) works fine either way.
Thoughts, pointers, things to look at, search results I didn't find that answer my question in grotesque detail? I'll be checking into a few more things.
-
What happens if you try a different domain like .home or .lan that were suggested here: http://tools.ietf.org/html/draft-chapin-rfc2606bis-00 but apparently went nowhere until the RFC expired.
I vaguely recall a discussion of some systems not liking some domains that folks were using internally.
-
I did try a local variant netname with no success. <something>staff
I also tried making a domain override to send that to the pfSense LAN address for DNS.
No luck with either.
Having noted where I can (manually) punch a netname into the DNS pane on Windows (adapter/settings/IPv4/advanced/DNS/) I found, to less shock than you might think, that the one (other than "none") that works is precisely the one (.local) the configuration page says not to use. I guess I'll give the configuration page conniption-fits and see if that breaks something else, or just fixes this.
I've been to that (Windows) pane many a time in the past, never have needed to put anything into that particular box, and expect I won't have to again - but it was helpful as a faster means of experimenting.</something>
