@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.

@gertjan said in DNS Overides: deep in the past Using my "Internet years" theory (like dog years) that's 7 Internet years ago.

@scilek said in Am I getting "Static ARP" wrong?: since they don't have manageable switched WTF? What sort of business doesn't have a managed switch? Even home users can have them, as they're so cheap. Avoid TP-Link though.

For visiting readers, the solution is above — this is just follow up. And additional thanks. @johnpoz -- Yup, you called it. ;) So, in a post-mortem, one should ask how that got missed by me. John's answer, "your "browser" or what your using to try and resolve these fqdn isn't using your dns - browsers like to use doh now.. which would point to some dns outside of your control" mentioned it, but my brain didn't pick up on it. When I read the phrase "fdqn isn't using your dns", I immediately turned to my client's operating system's DNS resolvers – and that pointed to pfSense. It simply did not dawn on me that something else might be transporting, what I thought was strictly local, DNS resolution outside my network. And, as so, I wasn't in a mindset to go looking for that. And, if I'm honest with myself, when I read "browsers like to use doh now" I completely misinterpreted that part of the sentence entirely. As the abbreviation doh all lowercase did not trigger anything to me as, at the time I read it, it was an unknown acronym that I didn't look up because was thinking he was saying this about 'browsers not using fully qualified domain names' (which he was not): [image: 1646178036143-doh.png] And, given that I had just – in err – having proved to myself I was pointing at pfSense, which it was, missed the subtly of what was actually being said. 'doh' didn't catch my attention, 'DoH' might have, but I was well down a different rabbit hole. Having never have encountered this kind of problem before, and aware DoH (DNS over HTTPS) was in use just fine in other environments I've messed with, I didn't give it the second thought that it so rightly deserved. Instead, I got hyper-focused on the 'forwarding' and 'DNSSEC' part, which were two things I went off to read about (and now in hindsight may not fully grok in the context of pfSense's unbound DNS Resolver). The security device is a Firewalla Gold. The way the hardware lab is set up is akin to this at the moment (it changes often): [image: 1646179800517-the-lab.png] At any given time either (or both) Firewalla devices may be removed; they tend to sit in bridge mode and send live notifications to my phone of devices being on the network that shouldn't be there (and give good insight to device details that are), further limit traffic by region, and provide alerts for certain kinds of activity or data usage patterns. It has identified a number of devices sleeping in the closet I'd forgotten about and my DHCP pool was happily assigning addresses to, but I was having a hard time tracking down. It has also alerted me to rogue behaviors certain applications and devices do at off hours; stuff I would not have thought to dig through logs to find. While I know they can act as firewalls themselves, I am extremely fond of pfSense and enjoy the low-level bit-twiddling granularity it provides. But there are high-level features pfSense simply does not provide (or I am ignorant of), and this fills those gaps when I'm not using the devices at external locations. I'm not interested in having Firewalla be "the" firewall, as this configuration isn't for a home (rather a personal lab for education purposes), and I have no minors requiring content restrictions or scheduled access times. I am acutely aware that it is possible to forego the need for two Firewalla devices (or even one) by integrating VLAN rules. Each Firewalla device has its own profiles, which I can compare behaviors. The current set of experiments are around keeping devices on various networks from seeing each other at level 2 and/or level 3 layers or only allowing certain kinds of access, such as from one network but not the other. I'm with you on not forwarding DNS, your arguments are sound, and I've been reading a number of security articles that say the same thing – much of the "protection" you think you're getting isn't real, as it can easily be determined by other ways. I'll have to look into DNS Over TLS (DoT), as that was entirely new to me as well. Part of the adventure has been stepping into the deeper part of the networking pool to improve my own understanding, and I hit that point where the gentle tapering swimming pool bottom suddenly drops to well beyond my height. Thank you again for all your help, insight, and advise.

No one is facing similar effects? Anyone an idea where this may come from?

@jknott yep, and I would have conveniently ignored it for years thinking it was normal. Oooops. Don’t be me :)

@bingo600 Yes, I have a config backup file. I still have access to the appliance. everything is working except dhcp. I'll reinstall the appliance. thank you

@vikd said in InterVLAN routing with DHCP on layer 3 switch: VLANs and interfaces in pfsense and not possible to hand out IPs via DHCP ? You can hand out IPs to network directly attached to pfsense, you can not hand out dhcp to a L2 network this is not directly connected to pfsense. If your routing these downstream of pfsense, then that is a different L2 network. All of your downstream networks would use pfsense to get to the internet, or could even use it for dns, etc. etc.. Or other networks hanging off of pfsense. But once you create downstream networks that router to other downstream networks at your L3 switch, this is not a directly attached network to pfsense and you wouldn't be able to hand out dhcp to those networks. If your switch can not do dhcp, then its a pretty crappy L3 switch.. But if it can not - then run something else on each of the L2 networks for dhcp. Or run something that allows you to create dhcp pools for non connected network - stand alone version of isc dhcpd can do this, etc. Then you would setup IP helper or dhcp relay on your switch to point to this dhcpd. But pfsense can not do dhcp for network that are not directly attached at the L2 level. If your wanting to route at your downstream and put pfsense in the same L2 as these networks, ie you created the vlan - then your going to run int asymmetrical routing problems unless you host route on all of your devices saying to get to some other network talk to yoru switch, but to get to internet talk to pfsense, etc.. The drawing I attached shows you how to properly do downstream networks, and also have a network or networks attached directly to pfsense..

Might be worth investigating that "...SSL certificate problem: certificate has expired", was that always the case prior to today?

@bmeeks @Infotactix Thank you both! Infotactix for the question and bmeeks for the response, that link you provided was spot on! I was about to loose my mind, thinking it was something I did. While this is a home setup and not crucial, it greatly adds convenience. I didn't notice it until I swapped out my cable modem and logged in to check my links and noticed that Dynamic DNS was returning 0.0.0.0 instead of my new IP. I tailed -f /var/log/system.log and saved and forced update and saw php-fpm[85765]: /services_dyndns_edit.php: phpDynDNS and a text output of an html file. Within this output, "That@M-^Ys an error.</ins><p>The server cannot process the request because it is malformed" followed by php-fpm[85765]: /services_dyndns_edit.php: phpDynDNS (): (Unknown Response). It took a bit of digging but I should have checked here first. But as my dad always said, "No matter how long you look for something, it's always in the last place you check."

@steveits Thanks for that, bit confusing how they capture the versions, I will rely on PFS to know whats most current version of the package. So would the Netgate site be the best place for the squidgard manual to configure the service?

It was broken in 2.5.2 as well, it was a 2.5.2 install that I had when I first opened this thread. I don't know what the best solution is. The file itself doesn't even have executable bit set. No I didn't list the full zfs exec set in the bug report. I am not sure why that path was chosen by the package maintainers, that's of course not the default chroot path used in a FreeBSD port installation (/var/named).

@gertjan said in Enabling DNS SSL/TLS Local Client: When you set up a TLS web server on port 443, why is (was) everybody still using port 80 ? Because clients do whatever they want ! Thank you Gertjan, I discovered that early this morning.

@viktor_g said in 2.6 / Dynamic DNS can not be saved or forced update - slow GUI leads to error 504: Please provide more info; Dynamic DNS provider and it's configuration Cloudflare, ZoneEdit, and GoDaddy are used. The dynamic DNS configuration of 2.6 is exactly the same as 2.5.2. tail -n 20 /var/log/system.log output after DDNS update attempt Feb 21 07:53:29 rt0 syslogd: kernel boot file is /boot/kernel/kernel Feb 21 07:55:09 rt0 check_reload_status[446]: Syncing firewall Feb 21 07:55:17 rt0 php-fpm[95131]: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wancloudflare'rt0.dyn.*.*'0.cache: *.*.*.* Feb 21 07:55:17 rt0 php-fpm[95131]: /services_dyndns_edit.php: phpDynDNS (rt0.dyn): (Success) rt0.dyn updated to *.*.*.* logs look normal and the IP has been updated. However, the GUI showed 504 Gateway Time-out nginx

I stopped using the pre-defined Service Types, and decided to select "Custom" instead. I used the following settings to get things working for Google Domains Dynamic DNS Interface to monitor WAN Interface to send update from WAN HTTP ASI SSL/TLS Options Checked Username (from Google) Password (from Google) Update URL https://domains.google.com/nic/update?hostname=YourSub.YourDomain.com Result Match good %IP%|nochg %IP% My guess is that the Update URL was changed in the in the Pre-Defined service type. Using the "Custom" type should prevent that from happening in the future. This worked for me even without installing "Added System_Patches"