@johnpoz said in Static Address ARP IP/MAC Flapping - Syslog: @robbiett nothing on my network does this.. So I don't have a easy way to test it.. I don't have anything bonded in my nas.. I use to use smb3 multichannel for better speed, but I just setup each interface with their own IP.. So there was never any moving of or announcement of IP on different interface like what can happen with that adaptive loading setting. I have since then moved on to just using a single 2.5ge interface to break the 1 gig barrier, etc. I do have IPs set on both interfaces of the RS819 but the thoughts on using smb3 multichannel may have unlocked part of the mystery. One of my other Syno units (RS217) does have multichannel set and does not display the same behaviour. One of the side-effects of using smb3 (at least on Syno) is that the ports remain at 1GbE when the unit is 'off' [ports 17 & 18 below] so perhaps that stabilises things. Without multichannel set they drop to 100 MbE when 'off' as shown on ports 19 & 20 - which is the unit that has the odd behaviour: [image: 1680113106410-2023-03-29-at-19.04.24.png] I agree that having servers running at greater than 1GbE makes things much simpler and I have a couple running on single 10GbE links on the blue ports above. It will be a few years yet before the last 1GbE servers tumble from my network though. I'll configure the RS819 for multichannel and see if it changes things. ️

@gertjan I'm talking about config files. I mentioned BIND above and stub zones. I think context let's you know I know what an Authoritative server is. I also talk about using Unbound and BIND in conjunction. Indicating I know they each serve a different purpose. Otherwose, why would I have both? :) Also, talking about nxdomain typically let's you know a person knows what recursive DNS is. I Googled where the config was earlier for pfsense. When installing Unbound on an actual full OS - you get a directory and the config looks for *.conf in that directory. My overall issue was just needing to know where the config was in regard to pfsense because I knew it wasn't going to be /etc/unbound. And knowing how pfsense handled config entries out of the box. Whether it used a separate config, the main config, or something else. Thanks for the reply. Appreciate your time.

I raised a similar topic back in 2021 or so. This would be a really nice feature of the pfSense. Since all my networks behind a l3 switch, there are also other functionalities that are not working such as pfblocker etc.

@admrm pfSense doesn't know about local DNS unless you set up a domain override, which will forward all queries for AD to the server(s) listed in the override. A host override will work for the domain itself but not PCs or other entries in AD DNS (inside the AD domain). The General tab is for pfSense itself to make DNS queries, which is different than devices querying pfSense for DNS. Edit: DNS issues on Windows can be sporadic because Windows does not query DNS in order, it uses the last known good DNS first. So it can adjust ordering if it tries to query while an AD DNS server is rebooting for example.

@etoel said in DNS resolver stops working after a while: Is the added suffix the problem? If so how do I get rid of it? The problem is ..... we - that is you me and nearly everybody else is doing it wrong. Launch this in a pfSense SSH or console : tail -f /var/log/pfblockerng/dns_reply.log Now you have a nice view on what the resolver does. On a 'dos' command prompt, do a nslookup google.com You will see 2, 3 requests for google.com in the log, the first with the "Connection-specific DNS Suffix" appended. Now, again : nslookup google.com. Did you see the dot at the end ? That is the correct way of spelling a host name. Now, nslookup will not insist by adding the local "Connection-specific DNS Suffix". As the final dot means : this is the end, nothing comes after this. You'll see just on or two google.com. DNS requests in the log. No more "Connection-specific DNS Suffix" added. One, or two, A and/or AAAA is asked. Btw : Enter nslookup without options, and then type help + enter. Type set d2 + Enter and now do a test again, like google.com and now you can see what happened as you have debug mode level 2 activated.. Btw : I'm running 23.01 and 4100 (that's a small 6100 ;) ) - with the latest pfB 3.2.0_3. Resolver settings are 'vanilla', which means I'm resolving. My DNS resolver never dies on me. Btw : DNSSEC is activated. Works great ..... I guess, as I never noticed an issue.

UPDATE By searching for similar Topics I ended up in this pretty interesting thread: https://forum.netgate.com/topic/141647/dhcp-not-registering-hostnames-in-dns/10 So I just cat /var/unbound/host_entries.conf while two clients were connected. There I could not find any hint of the domain names set via services > DHCP Server > domainname (respective tab for each interface) From the absence of any Entries there I subsume that the behavior I am seeking is not provided?

@viragomann said in Client VPN and IP leaking: How does the client route the traffic? Does it set the default gateway or only route partially? My question how to check ! But without VPN on client side , DNS leak test show me my IPS address is it normally with my above settings?

@johnpoz Thanks. I missed the "register static" checkbox . It works now !

@johnpoz Yes, sorry. Feel free to edit the original subject. This was effecting 23.01-RELEASE (amd64) built on Fri Feb 10 20:06:33 UTC 2023 FreeBSD 14.0-CURRENT

I'm sorry, but I still have a problem. I created the bridge between LAN and LAN2, I assigned an IP range to the bridge and I created the Firewall rules. All clients work outward, but I don't understand why LAN connected clients don't see LAN2 connected clients: what did I forget? What should I do to make them visible to each other?

Before anything I would like to thank you for your answer and for being so active here. This community is truly amazing :) @gertjan said in mail DNSBL queries resulting in NXDOMAIN: Put your email server not behind a device that places in RFC1918 land. I concur, however, the problem here is the 127.0.0.0/8 range not the standard RFC1918. I might be wrong but I can't see that range listed in RFC1918 I did some more digging on unbound and found this regarding the setting used for DNS Rebinding Prevention on their documentation: (can just read the last paragraph) [image: 1679070977368-cf6f3801-bd53-4a8b-8ad7-36287e4f7e39-image.png] @gertjan said in mail DNSBL queries resulting in NXDOMAIN: That file, as everything config file is generated and maintained by the pfSense GUI. So editing it won't work. Because : You edit the file. You restart unbound ..... with the GUI => wrong ! the config file has just been rewritten. You are totally right :) somehow that flew right over my head @gertjan said in mail DNSBL queries resulting in NXDOMAIN: so do what is proposed : So I decided to go this route with a some small modifications (for now..): I disabled DNS Rebind Check. Then re-added RFC 1918, excluding 127.0.0.0/8. Through the "custom options" section on the DNS Resolver tab.

@johnpoz Thank you! I’m off to read that link!

@alex-5 Thanks. That’s got to be the only thing I haven’t tried yet. Separate poe unit ordered and on the way.

@jimp said in Display Status: DHCP Leases with all 3 digits?: There is also the lazy method: Click the "IP Address" column header on pfSense to sort them before copying. There are not enough facepalms for me this morning. I do this all_the_time and I didn't think about that before copying. Thanks!

@wujj123456 said in Concurrent/Rapid DNS queries fail randomly after 23.01 upgrade: but disabling DNSSEC and leaving forward mode and DNS over TLS doesn't. Been using 1.1.1.1 (host name one.one.one.one) and 2606:4700:4700::1111 (host name one.one.one.one), port 853 = TLS. Just to test, for 3 weeks. DNSSEC disabled of course. I didn't detect any issue. Went back to default : resolving (= not forwarding), DNSSEC actif. Empty [image: 1678778507547-8c9b4d01-81ac-4223-8339-67f8e85eb782-image.png] as : if all choices work well, the one with no settings is the one to prefer See here.