Thanks jimp! I stuck to just using the allow mac address control and it worked the way I was expecting.  For some reason I got it in my head that the deny unknown clients needed to be checked for mac address control to work.

The results of trying pfSense 2.2 snapshot (pfSense-2.2-DEVELOPMENT-1g-i386-nanobsd-upgrade-20140711-1504.img.gz) are: The problem is still existent. The frequency of occurrence seems to be reduced. The last statement is weak. Due to lack of time my test was run only over 2 sessions each comprising 2 days. Session #1 had no problems, #2 experienced one loss of DHCP lease. Unfortunately I already moved from the respective site and will not return before december. For reason of stability I replaced pfSense with the o.m. combination of a Raspberry Pi and a TP-LINK router. So at present I am not able perform further tests.

colleagues, I'm willing to let the pfsense, DHCP and DNS control. In my current network structure use Windows Server as AD and DNS. The pfSense is behaving very much like DHCP server, and honestly see no problem with leaving the pfSense as a DHCP server. If anyone has instructions for configuring tinydns in pfsense because I like to test it as the primary DNS server. Hugs to all

Just a quick update.. I still can't get the system to forward anything other than ICMP requests, but I think I've found something else. It looks like for some reason pfSense is assigning the same adapter name (em0) to both my LAN and GUEST adapters! This would definitely explain what's going on! I'm going to try and find another adapter with a different chipset and report back!

Anything of interest under Status - System logs - Resolver?  If you go to System - General Setup - DNS servers, what do you have for a Gateway, none or something?

Do you mean you only want to see those DHCP leases from clients on a particular network, or you only want to serve IPs to clients on a particular network?

You can fix this by either configuring NAT reflection, or by getting your internal DNS server to point your domain to your internal IP instead of the public IP address.  I use the latter technique at work.  My external DNS is handled by a pair of Linux boxes, and my internal DNS is handled by Windows AD controller.  Even though my external Linux boxes handle our public IP, I added all my external FQDNs to my Windows AD controller DNS and pointed it towards the public server's (mail, web, ftp) internal IP addresses.  Works like a charm.  I found NAT reflection giving me pain when I was trying to connect to our FTP server by going out the firewall and then back in.

Anyone?

That worked! I'll take it and not ask why ;) I unchecked use tcp and put in the IP. Thanks!

I assume very little CPU and network is needed. I just did a release+renew on my desktop with Wireshark running, and the entire process took 2ms DHCP Discover: 4.7292 DHCP Offer: 4.7303 DHCP Request: 4.7305 DHCP ACK: 4.7312 Assuming perfect linear scaling, my box could handle 500/sec. It is a beefy quad core 3.2ghz CPU, but it's down clocked to 200mhz nearly all the time. Not a good test, I know, but I don't see DHCP being that intensive.

Sorry, my mistake! Once I select WAN, pfSense intelligently finds the external IP address (not directly the WAN address). Excellent!

Sorry it took so long to respond. Then next round in trying to get this implemented I tried it from my laptop again. This time the dns queries from there were also slow. To fix this issue, I took a backup of the config, did a factory reset on the pfsense machine and then imported back in only the aliases, firewall rules and nat rules. This time, everything went as planned an expected. Realistically, I still don't know what the issue was, but it is obvious that some place there was a configuration issue… Still though, thank you very much for your help. :) I have it in place and it took the companies internet speed up from the 65Mb/s up/down up the the 98Mb/s up/down that they should have been getting. Beyond that, it has been stable as I expected it to be.

The checkbox to use sequentially enables dnsmasq's –strict-order. Their man page describes that as: By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html The order in resolv.conf should match what you have configured under System>General Setup, at least assuming you also have no dynamic WANs or have disabled DNS server updates from DHCP/PPP. If resolv.conf has the order as desired, then I suspect either your internal DNS servers aren't responding for some things, or maybe dnsmasq's –strict-order doesn't do what you're expecting and stopping at the first server that replies (I would think it does, but not entirely sure off the top of my head). Getting a packet capture of all UDP 53 traffic on LAN and seeing what that looks like might be telling. Maybe your internal servers are failing to respond at times.

Wooops! Yes, the ovpns1 interface should in general just be left alone as OpenVPN manages that one for you.  The only thing I usually need that interface for is to create a Firewall Rule allowing all traffic on ovpns1. Glad it's working  :)