@McMurphy No you would need a web server. You could set a host override to a local IP then have that web server redirect for you.

@TGurlBridge said in Trying to resolve a repeating issue with separate subnets disconnecting other subnets.: Now I have that extra port unassigned on that NIC, assign it something later I guess, if needed. Now that sounds like a solid plan..

Yes, they will be added soon, hopefully in the next release it will have complete feature parity with ISC DHCP. It just isn't there yet. That limitation is noted in the release notes: https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#kea-dhcp-server-feature-preview-now-available

@Spyderturbo007 said in Slow to Resolve One Address: Name server Query time 127.0.0.1 10276 msec 71.242.0.12 28 msec So pfsense could get an answer from that 71.242.0.12 but clients asking unbound on pfsense that would never be used, out of the box unbound is a resolver - meaning directly talks to the roots and then works down to the actual authoritative ns for a domain. You can do a dig + trace on pfsense to see where its getting hung up, maybe your network is having a hard time talking the authoritative ns for that domain. I am not having any issues with it.. here is dig +trace from my pfsense. [23.05.1-RELEASE][admin@sg4860.local.lan]/: dig -4 gis.dauphincounty.org +trace +nodnssec ; <<>> DiG 9.18.13 <<>> -4 gis.dauphincounty.org +trace +nodnssec ;; global options: +cmd . 71187 IN NS g.root-servers.net. . 71187 IN NS h.root-servers.net. . 71187 IN NS i.root-servers.net. . 71187 IN NS j.root-servers.net. . 71187 IN NS k.root-servers.net. . 71187 IN NS l.root-servers.net. . 71187 IN NS m.root-servers.net. . 71187 IN NS a.root-servers.net. . 71187 IN NS b.root-servers.net. . 71187 IN NS c.root-servers.net. . 71187 IN NS d.root-servers.net. . 71187 IN NS e.root-servers.net. . 71187 IN NS f.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b2.org.afilias-nst.org. ;; Received 486 bytes from 192.33.4.12#53(c.root-servers.net) in 11 ms dauphincounty.org. 3600 IN NS pudding.dauphinc.org. dauphincounty.org. 3600 IN NS flan.dauphinc.org. dauphincounty.org. 3600 IN NS custard.dauphinc.org. couldn't get address for 'flan.dauphinc.org': not found ;; Received 170 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 213 ms gis.dauphincounty.org. 3600 IN A 198.185.140.22 dauphincounty.org. 3600 IN NS custard.dauphinc.org. ;; Received 113 bytes from 198.185.140.20#53(custard.dauphinc.org) in 44 ms [23.05.1-RELEASE][admin@sg4860.local.lan]/: you could see there was a bit of problem with one of their name servers couldn't get address for 'flan.dauphinc.org': not found See how I did a -4 on mine, this forces only IPv4 if you don't put in that it might try IPv6.. so you could see if with IPv6 is where your having more an issue.. you can see the time required on each step.. of the full trace, once something has been looked up before the NS for the domain are cached and doesn't have to do a full resolve.. if you are having issues with a specific domain, one method of a work around, is setup a domain override in unbound to say vs trying to resolve dauphinc.org. just forward that to say 8.8.8.8 or 1.1.1.1 or quad9 servers, etc. You can see from here - their dns isn't very robust let us say.. https://dnsviz.net/d/dauphinc.org/dnssec/ I see a bunch of errors that should be corrected with their setup. Another dns testing site also shows a bunch of issues with it. https://mxtoolbox.com/SuperTool.aspx?action=dns%3adauphinc.org&run=toolpage [image: 1698875049924-problems.jpg]

@ejimenez03 well if your mac is moving to different interfaces because your pfsense is a VM, then yeah that could all kinds of issues with your network..

Just to recap, I couldn't use Unbound in resolver-mode for those mx because sites like zen.spamhaus.org wouldn't work with it, I don't know the reason. Also I couldn't disable rebind protection because split-DNS wouldn't work anymore when I was using my domain with DNSSEC. So I have to use a third party DNS-server for those mx which is not blocked by spamhaus.org and alike. And because I still have a need for some split-DNS like behavior for my mx, I made a port forward from one external to one internal address in pfSense to cope with that. And it is running smoothly now. But it is more complicated than I had imagined.

@gwaitsi AS shown in the other thread I've mentioned above : packet capture on the interface used, and add the IP of the device. Start the capturing. Now, connect the device. Tell us what you saw .... @gwaitsi said in Android Limited Connectivity: no windows or linux machines are effected Neither apple devices, they work fine also, right ?

@Rastikan .local is a bad choice. This is the mdns domain, and why some of your boxes prob answered before is they answered to a mdns query which is just a multicast that a client sends out and asks hey everyone if this is your name answer. I would suggest you use something other than local for your domain.. home.arpa is the recommended domain to use.. example. $ ping nas.home.arpa Pinging nas.home.arpa [192.168.9.10] with 32 bytes of data: Reply from 192.168.9.10: bytes=32 time=1ms TTL=64 Reply from 192.168.9.10: bytes=32 time=1ms TTL=64 If you have done a recent install of pfsense, this is what it would default too. Registering dhcp can work, but it can also be problematic if you have a lot of devices, and your dhcp lease time is short.. I would suggest you setup dhcp reservations so your devices always get the same IP.. And then have it register those, this is a one time thing when unbound starts.

I hate the magic, but the problem self-resolved :( I got another public IP update and everything started working again. For the record, the IP change was 174.93.x.y (good) -> 70.53.x.y (bad) -> 174.95.x.y (good) I checked the range registration on ARIN and it is at least 2020; did not find it in bogon list.

Hi @viragomann, Thank you for your reply. No opt3 my interface list only igb and vmx interfaces but from the downloaded configuration it looks like opt3 is the reference for the interface - looks like no issues here. Both WAN01 and WAN02 Gateways are online and active. I tried the policy based routing you mention and it works, I am able to ping the dynupdate.no-ip.com with WAN01 or WAN02 selected as destination (I also confirmed the hits on the rule during both tests).

@keyser Yes, with some packet captures I found, that the DNS-requests are send from the WAN-IP-address. DNS resolver outgoing network interface was set to default "All". So of course, I did not get response from the private IP-addresses of the DNS-servers on the remote site. So I tried to set the outgoing network interface to LAN, which worked. Then I set it to WAN/LAN because I do not want to send all DNS-requests to remote-site. This seems to work, I can resolve the domain.local with the internal remote-DNS and all the internet addresses with the public-DNS.

@jsturm have you worked through these? https://docs.netgate.com/pfsense/en/latest/troubleshooting/ha-dhcp-failover.html

@jimp That makes sense as this machine was taken back to a virgin 23.05.1 state and the patches were applied en-masse. ️

@lpfw it is open source after all here is the "Firewall Logs" widget on the dashboard [image: 1697740994522-screen-shot-2023-10-19-at-2.42.59-pm.png] since it is only display 10 (my setting, because on my dashboard anything more than that makes want to scroll, and I don't like scrolling dashboards.) --- wait oh my is that name resolution working - FWIW, it is not any slower I won't keep this because 2 lines of code added, and I don't need it, but as a POC there it is. [image: 1697742379152-screen-shot-2023-10-19-at-3.05.29-pm.png] as a side note, some people have crazy long name records. Already displaying in a smaller font, and I still have to wrap to fit the table provided by the widget. So when there is a will there is a way. Enjoy the ride.

@Nan0tEch said in Unbound doesn't resolve 1 query: checking if i use a vpn while resolving the query and denying the request. This is quite possible for sure..

@Ducati0927 said in DHCP Static IPs not allowing UnRaid server out.: was able to connect to perform the download prior to upgrading UnRaid So it worked before you upgraded it.. Why would you think it something to do with pfsense?

@Gertjan Thank you for the valuable information. I ended up reloading the configuration file and started back from scratch. All is well now. Once again, Thank you for the support!

Two things come to mind immediately that can result in unbound restarts. Having the DHCP server register hostnames in DNS. Some IoT devices can do really dumb stuff like renewing their lease very very often. Because of an unbound limitation in pfSense, the only way to have the new DHCP host leases be resolvable is to restart the unbound daemon each time DHCP issues a new host lease (if you have "register leases in DNS" enabled under the DHCP Server configuration). pfBlockerNG, if installed, can restart unbound when certain of its features are enabled, but generally that would not be every minute unless you chose some extremely short list update interval. Obviously if unbound is frequently restarting, that is going to cause DNS issues because the daemon can't resolve when it's not running and instead is being restarted.