Makes sense, thanks.

NogBadTheBad, Well I learned how to install Wireshark and get the basics working so I could try your suggestion and I'm fooling with different filters now. I've identified several of my unidentified IP address owners and am busily plugging them into the static leases settings. Thanks!

Why are you using hostoverrides? If haproxy listens on the wan-ip, and the domainname resolves to that wan-ip, then the request should be handled by haproxy..? And if your using different subnets for clients and servers, there is little that can stand in the way.. (Otherwise try and disable transparent-client-ip if you have that set on the backend..)

Thanks for leading me in the right direction. I ended up recreating the VPN Gateways at System / Routing / Gateways and using hard coded IPs as GW instead of "dynamic".

@tlm4594: ipconfig /all I only get my default gateway as the dns server- 192.168.1.1. Is this okay? I find it odd that it's not handing out 1.1.1.1 or 1.0.0.1 as the DNS. This is normal and standard. PFsense, like many other firewall and router boxes runs a local DNS service, which in between other things CACHES DNS resolutions, so repeat DNS requests don't have to get out to the Internet, which takes time, to resolve, the local DNS service answers within a millisecond. Now you can certainly force PFsense to hand you the 1.1.1.1, if the extra time it requires to execute your requests is intentional.

This is great, i have grabbed and configured, but i have a quick question to the knowledgable before messing up my DNS resolution setup on my pFsense. I have a split DNS where i use "DNS Forwarder" to maintain my internal address's (including the DHCP address), I would like the dnscrypt-proxy to accept all the calls from the DNS Forwarder that it does not handle itself…  so DNS Forwarder > DNSCrypt Proxy > Remote DNSCrypt Server. I am considering putting the DNSCrypt Proxy on its own internal address and pointing the whole pFsense DNS resolution at the new internal proxy address, is this the sensible way to do it or should i be doing something else?  It feels a little clunky to add yet another step - and from the config docs for DNScrypt Proxy it would seem to be able to do everything that the DNS forwarder can do already but of course it will not have its own CP pane and not integrate with pFsense in a unified way. Any thoughts from knowledgeables would be appreciated.

I run the pfSense WAN port in DHCP mode behind a cable modem. That is entirely normal with cable modems, at least with Hitron¹.  I see the same thing.  You are sharing a cable with many other subscribers.  Those are arp requests from the CMTS (head end) to all the subscribers on your segment. 1. I don't recall seeing it when I had a Cisco modem.

Ok I found the solution the parameters need to be in the correct order  60, 61, 77 dhcp-class-identifier "sagem", dhcp-client-identifier 1:90:xx:xx:xx:xx:b0, user-class "'FSVDSL_livebox.MLTV.softathome.Livebox4"

working as expected in 2.4.3 #Choose internal interface as upgrade source #outbound NAT ( with this workaround rule disabled  ) LAN    This Firewall    tcp/udp/*    int.dns.ip.ip/32    tcp/udp/ 53    lan.int.ip.ip/32    *      DNS dynamic update  from WAN to internal DNS server Thanks !

Finally, and I am pretty sure it is Finally, I have found the problem. Nothing to do with my internal DNS or pfSense on my SG-1000 but the external Cisco Router/Modem provided by my ISP. That was blocking Pings, so no wonder there were lots of ICMP UDP Port not found errors instead of a reply with the address of the servers on the tcpdump output. This seemed to be intermittent so very difficult to track down. Hooray!!! And another thank you to jonpoz for helping me. Regards

A little update. I can ping from my WAN connection now but still have no direct link to a DNS6 name server. I'm not sure what option I might be missing or if its even an option at all but I am sticking with the resolver. At some point I might figure this out but until then failover to DNS4 is working fine. Any ideas are welcome.

Now back at home with a stable Gigabit environment & updated to 2.4.2_1… The WAN port auto-negotiates a 1000BaseT connection, and when manually selected, a 100BaseT: but when 10baseT is selected, there is no negotiation. Does this imply a problem with infrastructure, to with pfsense/SG1000? Where do I look further to verify this? I would presume that if everything works at 100/1000baseT, then 10baseT should be a given.

Or your finding the host name via broadcast or wins..  Or some other discovery protocol like ssdp or bonjour, ws-discovery (multicast) etc. etc..  There are many discovery protocols.. UPnP, LLMNR, etc. But if you want to use dns then the query needs to be fully qualified..

You forgot the CON on your last option that you will not be able to resolve anything local. Your going to have to be specific on what your "secure your DNS queries" is in regard too… Not all of us have our tinfoil hats on so tight that we are worried about our ISP sniffing our traffic to find our dns queries out.  Nor are we worried about the authoritative NS for a domain, or the roots knowing what IP we are asking for some FQDN from, etc. So when you want to discuss "secure" your dns your going to need to spell it out so we know what your wanting to "secure" it from.. Out of the box pfsense resolves and uses dnssec.. This should be optimal configuration for typical use that the person has not cut off the blood flow to their brain with how tight their tin foil hat is ;) Using something like opendns or quad9 have feature that resolving your own does not support and that is filtering out bad domains per some listing.  Now you could do this your self in unbound or with pfblocker and still resolve.  So vs handing over everything to some 3rd party company that says hey we have these lists of bad sites and wont resolve them for you.  You could do that yourself on pfsense and never send the query out in the first place. If you do not want roots to know your looking for say www.domain.tld, you can turn on a setting to only send roots .tld and second level roots domain.tld and not send... But from my experience that are many domains that this is broken for.