I hear ya, I would consider myself overly-curious as well. I did those updates in a couple of minutes, if you have any suggestions on  rewording or better examples - just let me know and we can edit the page. You don't seem to have all that many posts as of yet, but if you wanting to contribute to making the wiki better.. You can ask for an account and can create your own pages and edits, etc. I am a big fan of too much information ;)  Helps with the over-curious nature..  And examples of what happens and how it works is always a good thing.  Pictures can paint a 1000 words sort of thing.

@phro: Thanks for the tip! Seems my ISP has two DHCP servers battling for control of my network segment and pfSense is smarter than the other routers I have plugged in which don't seem to care about such foolishness. I may just put a dumb gateway between the modem and pfSense to bypass their weirdness. FWIW, this is a valid means of deploying redundant DHCP. The expectation is that hosts will use the first answer to arrive. This is why they include the source of the lease so that it can query the issuing dhcp server for renewals.

You need to add your Option 120 and 43 into the /etc/inc/services.inc file like discribed here http://tohamey.blogspot.de/2011/10/configuring-linux-dhcp-to-work-with.html Enable ssh support to your pfsense and conect to a shell. vi /etc/inc/services.inc Search for /* write dhcpd.conf */ and then for $dhcpdconf = << <eod<br>between {$custoptions} and default-lease-time 7200; you can add your options for vendor class like […] {$custoptions} class "vendor-classes" { match option vendor-class-identifier; } option space MSUCClient; option MSUCClient.UCIdentifier code 1 = string; option MSUCClient.URLScheme code 2 = string; option MSUCClient.WebServerFqdn code 3 = string; option MSUCClient.WebServerPort code 4 = string; option MSUCClient.CertProvRelPath code 5 = string; option UCSipServer code 120 = string; subclass "vendor-classes" "MS-UC-Client" { vendor-option-space MSUCClient; option MSUCClient.UCIdentifier 4D:53:2D:55:43:2D:43:6C:69:65:6E:74; option MSUCClient.URLScheme 68:74:74:70:73; option MSUCClient.WebServerFqdn 70:6F:6F:6C:2E:63:6F:6E:74:6F:73:6F:2E:63:6F:6D; option MSUCClient.WebServerPort 34:34:33; option MSUCClient.CertProvRelPath 2F:43:65:72:74:50:72:6F:76:2F:43:65:72:74:50:72:6F:76:69:73:69:6F:6E:69:6E:67:53:65:72:76:69:63:65:2E:73:76:63; } default-lease-time 7200; […] Next step is to search for  /* is failover dns setup? */ in your /etc/inc/services.inc And then for option routers {$routers}; between $dnscfg and EOD; you can add your UCSipServer […]       option routers {$routers}; $dnscfg option UCSipServer 00:0B:70:65:70:77:6D:7A:30:30:33:34:36:03:63:77:77:03:70:65:70:03:70:76:74:00; EOD; […] The empty line is mandatory, because of formating of the dhcpd.conf that will be created out of this. Now go to your DHCP konfiguration on your pfsense WebUI and save it like it is. Check on WebUI status->services if the dhcp server is up and running. Check on ssh shell the generated dhcp-server configuraion file with less /var/dhcpd/etc/dhcpd.conf Cheers to anybody need to make PinAuthentication work with Lync and PFSense ;-) BR</eod<br>

not sure why i didnt notice/check this after i figured out what was causing the ping issues, i still cant access my NAS drive when on vlan10 even though i can ping the NAS and i am not using local in the host name (as per the text in the pfsense settings). thoughts?

If it actually had 16382 items on it, broadcast might (or might not - I'm not sure without trying it) be a bit of an issue - actual number of hosts on it now would fit in a /22, but it was enough of a pain re-addressing everything that I thought long and hard about how far it might grow, and then added a couple of bits to be safe. That net has a larger number of users, and more "personal devices" on it - when it was a /24, I ran out of DHCP addresses for 85 users when users started to have a computer, and a phone, and an iPod (or equivalent), and an iPad or other tablet, and an e-book-reader, and who knows what else all looking for an address. Not every user, but enough. My crystal ball said go absurdly big, but still didn't think I needed to go all the way to a /16. If that one was a /22, I'd be getting close already. The one that's a /22 is an inherently smaller number of users, but I quadrupled it anyway when I had to re-address it for other reasons, as the other one showed me the writing on the wall. I'm pulling for IPv6 to finally deliver the promised land one of these days… <edit>Similar to Stan, I use the increased address space to apply some logic to my addresses. I used to have that on a /24, but as things grew over 15 years it became harder to manage as the reserved addresses for this had to be used so that would fit. I have both "types of service" and physical location prefixes.</edit>

You need to download that and view it with wireshark.  I would assume its asking for info

Depending on use - for a site with mostly the same users, just reserve them addresses (in the pool or out of it) and they will stay put. I use a pool, but assign non-pool addresses to known users, which helps to make unknown users more visible, and known users easier to account… For a site with a small number of variable users, use a smaller pool. But that does not sound like what you are doing. But, for a site with a small number of pretty much the same users, a smaller pool also works. IME the usual behavior (quasi-static in the pool) is more useful than not. But the benefits of setting them up DHCP-Reserved-static (easily done right from Status/DHCP Leases in 2.0.2) is huge if you are not running something like an airport hotspot with mostly transient customers. Even if you haven't sorted out which computer is which, you can assign them to invariant addresses, which makes checking the opposite direction and rearranging easier. My networks (on NAT) recently went from /24 to /18 and /24 to /22 to deal with the explosion of accessories that want an IP address - I used to have a pool the size of my userbase and room to spare in a /24. The /18 is probably overkill, but I didn't want to go back and re-do it.  If you make sufficient space in the NAT, it's easy to have a pool that's large enough for whatever you haven't reserved an address for, and room for all your users/devices reserved, and (if you don't have the sort of policy that forbids devices you don't know the address of from any use of the network - in which case you don't need much of a pool either) space to reserve the ones you have yet to determine which or who's they are that isn't your more logically arranged space.

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>

What about using VLANs?

Great, thanks very much. Running xmllint let me know that I wasn't closing a hostname tag. Thanks! –Matt

I have a same issue since same upgrade: Feb 14 01:03:00 dhcpd: dhcp.c:1323: Failed to send 300 byte long packet over fallback interface. Feb 14 01:03:00 dhcpd: send_packet: No buffer space available Feb 14 01:02:25 dhcpd: dhcp.c:3263: Failed to send 300 byte long packet over em0 interface. Feb 14 01:02:25 dhcpd: send_packet: No buffer space available Feb 14 01:02:21 dhcpd: dhcp.c:3263: Failed to send 300 byte long packet over em0 interface. Feb 14 01:02:21 dhcpd: send_packet: No buffer space available Feb 14 01:02:13 dhcpd: dhcp.c:1323: Failed to send 300 byte long packet over fallback interface. Feb 14 01:02:13 dhcpd: send_packet: No buffer space available Every time when 100% WAN bandwidth utilization. You can avoid it (and get more another problems) by delete the parent bandwidth value. So 2 possible causes IMHO: bad new heuristic algorithm for tbr size value or just bug. Does anybody solve the issue?

so if using mydomain.com as your search domain – if you query for just srv1 then client would auto added mydomain.com to the query. If your wanting just a host enty for srv1, that would not go in resolv.conf -- that would be in host file on either client or pfsense.  And would be IPaddress then hostname like 172.16.100.100 SRV1

@johnpoz: Now another option I believe is editing the dhcpd.leases file  to add the reserved; […] We've looked into that before and decided it wouldn't work. That relies upon the client requesting an infinite lease time and having infinite-as-reserved on. If the client doesn't specifically request an infinite lease time, it doesn't apply. Also this part: Leases  may  be  set  'reserved'  either  through OMAPI, or through the       'infinite-is-reserved' configuration option (if this is  applicable  to       your environment and mixture of clients). It doesn't mention that being a valid option in the config for a fixed address. It appears to be a flag on the lease itself in the lease database, not in the DHCP server config. Maybe they changed it and it works now and the man page is just behind, but from the sound of it, it doesn't do exactly what you're hoping for here. If someone wants to hack that keyword in and see if it works, feel free. If it does work, we can add the feature in.

That works as well.

ok, no one has an opinion or experience with this… I guess I'll try it and report if it works or not... :-\