looks like dns resolver was on and dns forwarder was off

Figured it out, wiped the ssd to do a fresh install - and upon autodect of wan/re0 I got a duplicate mac address - at one time I set it the same as the dsl modem. Blanking out the mac address line in the GUI for a adapter - does not set it back to its factory address?  This MB has 2 adapters, so I just set it one less on the last part of the mac address and it was happy. Dont know why it did not work from the very start - but now reinstalling all the addons and rules etc Thanks for pointing me in the right direction what might have help for anyone else in the future - i did from windows cmd prompt a ipconfig /release then hooked modem up to pfsense Myk

ok, thanks!

Well you could always fire up a copy of freebsd, compile what you want and then move the files to pfsense.  for something as integrated into pfsense as unbound now is.  Might be better if you put in a feature request to have unbound compiled with this patch.

… and as usual, the DHCP server log will show what MAC pfSense is receiving - if it's in the "static lease map", the related IP will be proposed, otherwise one of the pool will be taken.

No. You will probably want to renumber the interface too. Might be able to make a better recommendation if you explain why they need to renumber their DHCP.

@cmb: You put them on a different network (interface or VLAN) and configure that interface or VLAN accordingly. You don't change subnets in DHCP on a single interface, you setup a separate DHCP server instance on a separate interface or VLAN. Is this possible not adding 2 new NIC cards?  Meaning, there is an area in the GUI that I can create a new DHCP instance, create a new subnet range and tell the router to use this 2nd one instead of the original subnet range? I'm working with one that is on a 1.x range, I need to change the range to 50.x

Thank you johnpoz and jimp, I think deleting the leases did it. Hadn't realized how long those hang around :-) I'll update as suggested if any more out-of-pool addresses appear. Cheers!

Huh??  Your saying you have a pool size of 100-126, and you set a reservation for .68, but your client gets a .73? Yeah no!  Not the way it works.. If the client has an OLD lease it will request that, you need to make sure you clear up any old leases that a client might ask for.  You need to make sure your not running an other dhcp server on your network that might hand out addresses. So if client had an old lease of .73, just because you set a reservation .68 does not mean he is not going to ASK for his old lease to be renewed.. So if the dhcp server has that lease then sure it will let him renew it..

Seems it is due to a 5 year old bug (https://redmine.pfsense.org/issues/1819) that should be picked up again soon.

Thank you for the help. It worked…

All good stuff there jimp..  And I agree with you for a specific record.  Yes it might be faster to forward to somewhere that has it cached. But what is the round trip time of that query, even if cached to that NS your forwarding too. What is the TTL of the specific record?  What is the TTL of the NSers down the tree.. So lets say I am looking up www.domainX.tld, once the resolver caches the NS for domainX.tld.. As long as that TTL is valid it does not have to go ask anything up the tree.  He has cached the NS for domainX.tld cached.  So if looking for record www, he just has to go direct to the NS for domainX.tled. Which you never know might actually be quicker to respond than who your forwarding too ;)  Even if that forwarder has it cached, if he doesn't then he has to either forward it or resolve it.. Which for sure could be slower than you just directly asking the NS for domainx.tld for www So lets say the ttl on www is 5 minutes.  So when your resolver looks it up again the ttl is always going to be 5 minutes..  But depending on exactly when your client asks for it and what the forwarder ttl time is.. And then when your client(s) ask for it again.  You could actually cause 2 wan queries for it when you would of only needed 1 if you would of just resolved it. If you get back a expiring ttl of 1 min, you can only cache it for 1 minute.. So if you have another client on your network ask for say at 2 min now you have to go ask the forwarder again.  But if you would of resolved it you would of had full 5 min ttl.  So your client that asked for it at the 2 min mark would of just gotten a cached value and a 3 min ttl for his cache. Yes your dnssec is going to add some time to your overall speed, etc.. But to be honest in the big picture you really should just run a resolver, unless you have some specific issue why you can not, like your isp intercepts dns, etc.  Or you have just really bad latency and don't want the added over head of walking down the tree from roots and extra overhead of dnssec. But once you get your cache going and depending on the actual use of your clients.. The difference that you might have now and then from having to resolve vs forward, with the added benefit dnssec, I don't see how couple ms here or there make a difference. To be honest if the user is looking speed up their internet because they think the resolver is slowing them down - then they prob have more issues than a couple extra ms to lookup something.

Ok you give a machine an IP via either just out of the pool or you create a static entry for it.  He gets a lease!!! Once he has that lease he will renew that lease until the cows come home.  So you either have to have the client release it!!  And then make sure he doesn't ask for it again, or delete it on the server.  So he can not renew it and then he has to ask for a new one.  Then he will either get his new static or he will get out of the pool range if you do not have a static set for him. I do this all the time.. I let a machine get a dhcp, and then I set a reservation for him.  I then delete the dhcp lease he got and once he goes to renew.. That lease will be gone, he will have to ask for a new one and then he will get his reservation. The web gui will not let you delete the lease if thinks its in use, via there is a arp entry for that IP.. So delete the arp entry then you can delete the old lease.. Or just manually delete the lease out of the leases file or delete the whole thing and let it get rebuilt as clients renew, etc.

A bit of further digging, I found that if I added a DHCP Static Mapping, it did show up in "Status -> DHCP Leases". /var/dhcpd/var/db/dhcpd.leases file still remained as before with the default content. Where is this static mapping maintained from isc-dhcp-server's perspective? On edit: Answered my own question, the DHCP Static Mapping goes into the configuration, hence it's recorded and persists. I'm tempted to add a path for the leases file to the dhcpd configuration.

Have not found any faults in logs. However, after random reboot (pulled the plug from the pfSense machine by accident), things started to work again. I will investigate it deeper if it occurs again.

I'm not sure about the custom data saved in the config.xml. My solution was to modify /etc/inc/services.inc as follows : /* write dhcpd.conf */ if (!@file_put_contents("{$g['dhcpd_chroot_path']}/etc/dhcpd.conf.auto", $dhcpdconf)). After that at every boot pfsense rewrites dhcpd.conf.auto not dhcpd.conf. Manually modify dhcpd.conf as you wish, it should be persistent between reboots or service restarts. The above solution is a hack, i do not recommend using it for production systems and it could completely break your pfsense install.

oh, is there a any way set a rule in pfsense for that, if a paticular IP request for DNS query that will be forward to google dns.

Because they didn't make a query would be my guess ;)  You need to actually Verify they are doing queries if your saying they are not logging..  So lets see the logs of your 1 client, and then what query are you saying is not being logged? Are these clients behind a wifi router that you thought you were using as AP, but its really natting so your only seeing the query in the log from its IP address? So from a client do a dig or nslookup or drill.. So it shows you doing a query to pfsense?  Sniff on pfsense interface they are doing the query too.. Do you see the query? > dig www.pfsense.org ; <<>> DiG 9.11.0-P1 <<>> www.pfsense.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31348 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.pfsense.org.              IN      A ;; ANSWER SECTION: www.pfsense.org.        300    IN      A      208.123.73.69 ;; AUTHORITY SECTION: pfsense.org.            218    IN      NS      ns2.netgate.com. pfsense.org.            218    IN      NS      ns1.netgate.com. ;; Query time: 35 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Mon Dec 05 03:42:32 Central Standard Time 2016 ;; MSG SIZE  rcvd: 107 You can see here what IP did query too.. ;; SERVER: 192.168.9.253#53(192.168.9.253) If I do a nslookup you can see what server its going to ask. nslookup Default Server:  pfsense.local.lan Address:  192.168.9.253 [image: dnsquery.png] [image: dnsquery.png_thumb]

Thanks johnpoz. Turned out I had disabled the DNS Resolver and saved the setting, but did not apply the change. Wen you leave the page and apply other pages, this page is not applied. You need to apply each page, if it's changed.  :-[ I also disabled the [b]Disable DNS Forwarder setting as you recommended. All seems to be working fine now. Thank you, appreciate your time and effort!

pkg: No packages available to install matching 'dnscrypt-proxy' have been found in the repositories