No I did not make any special rules. I will check the settings when I get home tonight to see what I have enabled. Thanks for the lead.

Move the forwarder (dnsmasq) to port 5353 (or something else), then setup NAT rules to redirect your local interface queries to localhost:5353 and then your local clients can continue to perform recursive lookups via dnsmasq even with some other DNS server using port 53 for authoritative responses.

do I interpret these wrong?

Yep, that works. I removed all the DNS servers from System:General Setup, and had both these unchecked: Allow DNS server list to be overridden by DHCP/PPP on WAN Do not use the DNS Forwarder as a DNS server for the firewall This makes /etc/resolv.conf contain just: domain mydomain.xyz.org nameserver 127.0.0.1 Then in DNS Forwarder, Advanced: server=216.146.35.35 server=216.146.36.36 And in DNS Forwarder Domain Overrides I have entries for the various local domains, and local private reverse lookup zones and the IP addresses of the internal DNS servers that know how to answer queries for those (e.g. mydomain.xyz.com 10.42.11.1) Now when I "nslookup" from the pfSense command line, it can only ask DNS Forwarder. And DNS forwarder knows how to do "default" queries using the "server=216.146.35.35" line/s. And queries for local names and reverse lookups always get resolved correctly, or NXDOMAIN returned correctly if the local name does not exist. The missing element of this configuration is that I can't specify the gateway to use for each upstream DNS server. DNS Forwarder will be using the default route for all of them. That could be fixed by doing this a slightly different way: a) Add a checkbox somewhere (General Setup or DNS Forwarder config page?):   "Use only the DNS Forwarder as a DNS server for the firewall" b) When this is checked:   1) Still define routes through the specified gateways for each DNS server IP in General Setup.   2) Only put 127.0.0.1 in /etc/resolve.conf - so DNS lookups from apps on the firewall itself all go to the DNS Forwarder.   3) Write a separate /etc/resolve-for-dns-forwarder.conf that contains the IPs of the DNS servers specified in General Setup (or given by DHCP).   4) On dnsmasq command use "–resolv-file=/etc/resolve-for-dns-forwarder.conf" This way DNS Forwarder will be told about the upstream DNS servers automatically, they are routed through the selected gateway/s, and pfSense apps will always use DNS Forwarder to do their DNS lookup work. Does this sound like a reasonable enhancement to the system? And to me it actually feels like the behavior that many people would want - that DNS done by apps on pfSense itself uses the same path for resolving names as any ordinary LAN client. Or is there some catch-22 that I have forgotten here?

My Zoom modem didn't have weekend support, so on Saturday I went and got a Motorola SB6141. Since the change I have not had any problems with a rouge dhcp server assigning addresses. I don't know if the Zoom modem was my problem (the new ip addresses listed the Zoom as the server), but the upgrade to the Motorola cost $40. Maybe, you get what you pay for.

I rebooted and it was resolved. I changed nothing.

Thanks Phil!! Appreciate your input. Have a great day! Kell

@johnpoz: Well seems to me they cleaned up a bug or lack of check - since it should not be possible to create dhcp reservations for the same IP address - that is not a valid configuration.  What if both of them ask for lease?  So you have duplicate IPs on the network? Well, as for valid. This is supported by some DHCP daemons. I think one of semi-valid use cases would be subnet 10.11.12.0 netmask 255.255.255.0 {                                                    host mylaptop-wifi {                                                                          hardware ethernet 11:22:33:44:55:66;                                                  fixed-address 10.11.12.100;                                                  }                                                                                    host mylaptop-wired {                                                                          hardware ethernet aa:bb:cc:dd:ee:ff;                                                  fixed-address 10.11.12.100;                                                  }  } assuming I make sure to switch off the wifi before plugging in the wire.  ::) @OP: Just do as suggested above, you simply are doing things in completely wrong place!  :P

Hi phil.davis, thanks a lot for helping. My biggest problem was, that I have not found the custom-entry. Maybe the list can be sorted for the next release. My drop down only showed 5 entries… Nevertheless, it's working except the result. The result is XML (see exmaple below) and I don't know how to match it, because the description says the entered result must match the returned one but the xml is too dynamic. Any ideas or do you maybe know any wildcards to match it? <dnsapi_result><is_ok>OK:</is_ok>   <result_counts added="1" changed="0" unchanged="0" deleted="1"><actions><action action="SET" host="myhost.com" type="A" value="181.192.221.189"></action></actions></result_counts></dnsapi_result> Thanks a lot for helping, Thomas

@jimp: If you specify an allow MAC, all others are denied. If you specify a deny MAC, all others are allowed. Excellent, thanks.  That's exactly what I was hoping was the case.

Either turn on NAT reflection, or use split DNS - on pfSense DNS forwarder define host overrides that give the internal LAN IP of the various server/s in response to internal requests for the name.

Looking at dhcpd.log, I see some human readable lines, then a lot of "@^@^@^@^@", then it ends with "^@CLOG^@^@^@^@[<f3>^@^@|<d0>^G^@^@^@^@^@"[/quote] The logs are circular logs - maybe you are using "cat" to spit out the log at the command line, and you need to use the "clog" utility? clog dhcpd.log ```</d0></f3>

sweet, thanks guys for all the help and pointing me in the right direction.  ;D

Ah! That'll do.

Yes, when the pfSense WAN IP is a private one, the Dynamic DNS code is smart enough to use checkip.dyndns.org to find out what its real public-facing IP is, and use that to set the Dynamic DNS name. Of course, on your ISP device you will need to port forward ports in from ISP WAN to pfSense WAN, so that your clients in big bad internet land actually get through to pfSense WAN. Often with ISP devices they have a place to specify a "DMZ" IP address which is not a DMZ at all, it does a 1:1 port forward of everything to the specified IP address - which is what I always do. Then I get all the crap connection attempts from the public internet passed through to pfSense where I can filter (and log them if I care).

Jan 23 00:58:00 php: rc.dyndns.update: MONITOR: LTEPGW is down, removing from routing group Privat Those messages are spat out by /etc/inc/gwlb.inc return_gateway_groups_array() - whenever it is called it looks through all the gateway groups, calculates and returns the lists of gateways in each group that are up. As it does the calculations it logs any gateways that are down, regardless of whether the caller actually cares about the particular gateway or GWG. It could be cleaned up to not spam the logs like that! For you, it is just log noise. The dynamic DNS code will still be doing its thing OK.

johnpoz, Thank you for the reply. What you explained makes perfect sense in regards to the workstations being assigned their previous ip address in the dhcp pool. I am not going to delete all the leases in the dhcp gui for now,,Had plenty of work getting ip range changed over on the DC and such. The idea of the dhcp server assigning from high to lowest numbers doesn't seem to be holding true. The mobile devices seem to be getting 192.168.2.x number and i see only one 192.168.3.x device so at least I know the range is going into the "3" range. I guess the only way we will ever know if the "0" range is used if the device count goes beyond ,,about 750 devices on the lan at one time. Barry

^ my bad, yes domain overrides.. Just bottom of page under host over rides section under dns forwarder ;)