The follow-up post on latency issues is here: https://forum.netgate.com/topic/170660/latency-spikes-every-15-minutes-after-upgrade-to-2-6-0-ce

@viragomann System --> Advanced --> Networking I canceled the checkbox All IPv6 traffic will be blocked by the firewall unless this box is checked Next Interfaces --> WAN The section General Configuration -> IPv6 Configuration Type I changed from DHCP6 to None Now it seems to be working. I have to check it on other reboots as well. thx

@msswift I've made too many edits to last post so I'm being blocked as a spammer. Please cross out "The near end of the tunnel does NAT." It's neither true nor relevant.

@fandangos said in DNS Forwarder works but DNS Resolver do not work with docker container.: So I've found that I can fix it if I disable the DNS Resolver service and instead use the DNS Forwarder. My question is basically, why? Why DNS Resolver might be blocking the requests from docker containers? The Resolver uses an access control list. By default all local networks assigned to pfSense interfaces are allowed to access it. If you want other devices to access the Resolver you have to add the IPs or networks to the ACL on the Access Lists tab. So check how the docker requests the DNS server and if it either does at all. I understand DNS Resolver is great because there's no need for external servers providing the IP for an address, it can resolve it somehow (I have no idea how it's done). The DNS Resolver uses root DNS servers by default. You cannot configure them by yourself. However, in forwarder mode it uses the servers you've entered in System > General or even the ones configured by DHCP if applicable and you allow to override your settings. is DNS Resolver faster compared to DNS Forwarder? The Resolver caches host name IP pairs. So when you resolve a cached host name it would be faster naturally. Otherwise it won't really be.

@packetpirate Glad you figured this out! :)

@johnpoz I knew (something) about 'quick'. The FreeBSD pf documentation says : look here PF FAQ and there I find a lot of info. The quick Keyword As indicated earlier, each packet is evaluated against the filter ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the filter rules. The last matching rule wins, but there is one exception to this: The quick option on a filtering rule has the effect of canceling any further rule processing and causes the specified action to be taken. Let's look at a couple examples: I stand corrected

@beefer said in AVAHI issues after upgrading to 2.6.0: mDNS broadcast is replicated accross vlans, So sniff on the interface the printer is connected too - does the printer answer? When you see the discovery go out..

First, @bmeeks, I appreciate your advice to back off and deal with the DNS Resolver issue without the complications of pfBlocker. Plus I did not know that the DNS Resolver worked out of the box. @steveits said in DNS Resolver Not responding: Why is your WAN going down? This turned out to be a pivotal question. I started looking at my cable modem's settings. The modem's DHCPv6 Prefix is hard coded to 56, instead of 64 which is the WAN interface default, so I changed that. I also could not find anything in my modem that looked like a DHCPv6 configuration settings, just the prefix. The modem's not exactly young. So I checked Request Only IPv6 Prefix on the pfSense WAN interface... ...and... ...drum roll... I think it works! The DNS Resolver has been responding to requests for about 20min, and either logging is broken, or unbound isn't starting and stopping anymore. I keep staring at it and waiting for something to break, but so far, so good. Thanks to everyone for your help!!! And please stick around to help when I try to set up pfBlocker.

OK. I believe it's something to do with ntopng. Removing that package appears to have resolved the issue.

Why is there still no proper fix for this issue? It is still completely broken in 2.6.0 and both patches that are supposed to "fix" this in 2.7.0 are nothing but a mere workaround: https://redmine.pfsense.org/issues/12612 https://redmine.pfsense.org/issues/12613 With these patches applied every restart of a device connected to one of the in/out interface of the DNS Resolver causes a restart of the unbound service (including complete loss of cache and temporary loss of DNS resolution for all devices). This bug is going to force me to downgrade back to 2.4.5-p1 and will eventually make me chose another firewall solution in the near future. Sorry if I sound frustrated, but major bugs like this should not be ignored like this for almost a year.

@Gertjan Appreciate the test and useful information. You should be promoted to the highest level Moderator. It's helpful to warn users away from RFC1918 on public DNS, provided it's not obstructive or failing to imagine non-standard use cases. BTW been doing DNS for 20 years and it's only "BROKEN!!" if interferes with interoperability. My fringe use case: embedded Linux devices in QA networks, which for "reasons" can't use a private DNS server. Probably some homelabs also. Having to run nmap across a bunch of network blocks gets really old, fast. Anyways: thanks for the tip. https://freedns.afraid.org/

@johnpoz got it thanks!

@jimp Done! https://redmine.pfsense.org/issues/12892 Thanks for the help on this one! Cheers, Ben

@gertjan said in Split DNS Isn't Working?: @nollipfsense said in Split DNS Isn't Working?: NIC A NIC doing DNS ? A NIC is a bunch of electronics like capacitors and inductors for creating a good line impedance, a clock detctor (using a PLL), a big shift registers, some CRC bit test functionality. Some front end 'PCI' logic to make the NIC accessible for the CPU and DMA for the actual data transfer. A NIC might be able do take some useful decisions based on the MAC parts in the packet headers. Check the CRC for you. The on board ROM should be seen as a BIOS extension, so the NIC could be used by the BIOS to remote boot on OS or something like that. These are my words, but I'm pretty sure a NIC doesn't know what "DNS" is. It knowledge stops at the "TCP/IP" border, which is far lower on the OSI ladder. Yeah, I know it sounds funny and the way I said it with emotional twist at the time looking at the Freepbx interface and seeing DNS 10.8.27.1 grayed out, knowing it was the right opportunity to do a clean 2.6 install. While in the bios, I did thought about that, but it was too late, I already committed to a clean install long over due. The sad part is I swore that my latest configuration change was backed up, and it turned out to be a lie. The more one does it; the more one learns, I guess. I rebuilt both pfSense and FreePBX last night.