More or less, SNAT I believe. Tailscale offers a mesh-based Wireguard tunnel to access (for example) devices on your LAN without the bother of doing any router-side config. The device you're using outside the LAN (my iPhone) connects directly to public sites without going through the tunnel, but since I'm advertising my own LAN-based DNS to the whole Tailnet (the mesh), and that DNS is not itself running Tailscale, connections to that DNS system are routed from another system that IS running Tailscale on the LAN. The system being used in this case is pfSense, as what Tailscale calls a subnet router, so its IP shows up as the source of the DNS query on the DNS (AGH) system. Turns out there's a way for Tailscale to preserve the original IP, so I'm going to try that out. And so... Guess what happens when you set AGH to drop connections from pfSense? :) Yeah, no DNS on your mobile - which I ran into today as I tried, and failed, to stream music after just starting my drive.

@ITSGS_ thanks for this, just checked the notes for CE 2.8.0 here: and it looks like they have moved from API to PAT in this release: Users of the Gandi Dynamic DNS service must change their current API token to a Personal Access Token (PAT) as Gandi now requires this authentication method for Dynamic DNS updates. For uninterrupted Dynamic DNS service, create a new PAT and save that PAT value in Gandi Dynamic DNS entries before upgrading to this release.

@dlreid Well with that error you may not be able to upgrade either. You might try https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#rewrite-repository-information. But that topic may be a separate thread. :)

@Gertjan said in DNS Resolver starts rejecting requests over IPv6 after a couple of weeks: What version ? 2.7.2 When the issue happens, was unbound listening on IPv6 LAN interfaces ? Yes, I can confirm it was listening because the query is explicitly rejected, not timed-out. [25.03-BETA][root@pfSense.bhf.tld]/root: sockstat -6 | grep ":53" unbound unbound 53479 3 udp6 *:53 : unbound unbound 53479 4 tcp6 *:53 : means "all exiting interfaces", for TCP and UDP. I recently restarted it because the problem recurred, next time it happens I will run tcpdump and upload a capture of the transaction(s). When you raise the resolver (unbound) log setting to 'very verbose', can you see the IPv6 request arriving @unbound ? Don't forget to set the log setting back, as it produces a lot of info. Next time it happens I'll also do this.

@ChrisJenk Hmm, I have: [image: 1748888778169-c06f7223-67d7-46cb-ad56-915fdb1fe82b-image.png] and [image: 1748888797563-f9bd11e6-ab0c-48d9-8f27-57acbfc3d64f-image.png] and see an active lease: [image: 1748888860742-1a3af71f-5ca6-4a00-882f-fbb8b7315889-image.png]

@johnpoz hmm ok i thought i was done but maybe not. I have a bunch of smart bulbs. ive gone through and renamed them [ Services -> DHCP Server -> LAN] [image: 1748887094356-98966f2f-72e1-4ccc-bea6-85d2eddbdca9-image.png] but they still come through to pihole with their default names: [image: 1748887043486-4f474660-139b-4a4b-ab80-cec37f44af2e-image.png] How do i get pihole to pickup (pfsense to broadcast?) the hostname/description ive assigned it? EDIT: disregard, turns out it was a simple as giving it a few min to update

@johnpoz Yes we have them as static DHCP reservation on the router. But I removed them from that when we tried to fix this issue. All the devices (WAPs and network switches) went to the IP of 192.168.1.20... every single one of them. (We could see that on the cloud key, so we still had cloud key access somehow, but basically the entire network went down and just stopped working). We can try set the cloudkey IP static on the device, ill look into doing that. Im assuming the unifi devices talk to the router first to get their IP's, then talk to the cloudkey for other stuff, as you can run the equipment without the cloudkey. We are setting up a test lab today so hopefully can figure it out.

@tinfoilmatt Thanks for response but no. The issue is that pfsense was redirecting URLs and proxing them to some form of page it managed vs resolving the hostname provided and redirecting what is a CNAME in the public cloud as a form of resolution for "internet" sessions (such as ACME validation) but also an intranet IP/host. Within a SOA zone it manages Ex: Intranet test correct: dig +short traefik.core.acme.net shuffleboard01.core.acme.net 172.16.100.120 172.16.100.120 curl -k https://shuffleboard01.core.acme.net/index.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Shuffleboard Game</title> Internet test dig +short traefik.core.acme.net shuffleboard01.core.acme.net penguinpages.net. 18.234.137.234 penguinpages.net. 18.234.137.234 curl -k https://shuffleboard01.core.acme.net/index.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Shuffleboard Game</title> What I am stuggling with now is that along the way I was root causing acme HTTP-01 Cert setup with letsencrypt, and the current "fix" is to disable my enhanced firewalling "pfBlockerNG" [image: 1748865415665-c32d5c46-3018-4a6d-80a7-4aec67f1c313-image.png] but this is not sustainable. And I need to figure out means to ??? Whitelist" any letsencypt server, world wide. Then I assume I will have to return back to this URL redirect issue.

@smk Read "Kea DHCPv6 Static Mapping issues" : same thing ?

@viragomann I didn't even think of checking the browser's debug mode. It does look like the host header is being attached actually. But for some reason HAProxy isn't picking up on it. I do have HAProxy redirecting HTTPS to HTTPS, and it seems like that might be where the problem is. I disable that and just use HTTP, and it works. I do want to stick to HTTPS though. This does work for host overrides, but not DNS redirects. I have HAProxy listening on 80, with the action "http-request redirect scheme https code 301 !{ssl_fc}". Then I have an HTTPS frontend listening on 443. I also have a certificate for the wildcard subdomain. This has always worked in the past with host overrides. But now it won't with domain redirects, and I'm not sure why

I believe I've found the issue causing the weird behavior. In looking at the MAC addresses captured, I can see that the "wrong" address is 02:42:0a:08:08:02 When using macvlan, the MAC always defaults to matching the specified IP address, but the incorrect address above doesn't. So I then took a look at the lease table and saw this: [image: 1748792919895-screenshot-2025-06-01-at-11.13.53-am.png] Hmm... That's not right. But it's the same wrong number. Looks like it's ignored in 2.7.2 and not ignored in 2.8.0 I made an edit to the reservation, put the correct 0A in there and... Look at that, MAC comes up to match in 2.8.0 and replies start working. SonofA.... Now I can probably get going on the meat of this update (for me), migrating from ISC to KEA and the new if_pppoe.

Thanks for clearing that one out, never came up to think of ipv6 localhost!

@penguinpages i poked around a bit and tried to figure this out. still not clear at all what to do to enable TSIG for DNS and then enable local subnets to update DDNS and DHCP also to make updates. So far I think I have tried a few dozen ways to change.. and if you don't use GUI.. any GUI change just overwrites. So here is what I have so far Step 6: BIND DNS Create TSIG vi command line [2.7.2-RELEASE][admin@rt1.core.penguinpages.net]/root: tsig-keygen -a hmac-sha256 ddns-update key "ddns-update" { algorithm hmac-sha256; secret "wn6G9qxOZhDpfn+SUUeEX<snip>k51Tc="; }; Copy output stanza and paste in : service -> bind -> Settings -> advanced -> Custom Options: <paste key standza in box> Validate service restarted Now check if DDNS update via remote host will work export BIND_SERVER=172.16.100.1 export CERTBOT_DOMAIN=shuffleboard01.core.acme.net export CERTBOT_TOKEN="example-token-12345" # Replace with actual Certbot token echo 'key "ddns-update" { algorithm hmac-sha256; secret "wn6G9qxOZhDpfn+SUUeEX<snip>k51Tc="; };' > /tmp/ddns-update.key chmod 600 /tmp/ddns-update.key nsupdate -k /tmp/ddns-update.key <<EOF server $BIND_SERVER zone $CERTBOT_DOMAIN update add _acme-challenge.$CERTBOT_DOMAIN 300 IN TXT "$CERTBOT_TOKEN" send EOF update failed: NOTAUTH Baseline that use to work before update TSIG then after.. I can do updates and not pass key so.. meh.. its not working nsupdate <<EOF server 172.16.100.1 zone core.acme.net update add _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT 12345 send EOF dig -t TXT _acme-challenge.shuffleboard01.core.acme.net. @172.16.100.1 nsupdate -k ddns-update.key <<EOF server 172.16.100.1 zone core.acme.net update add _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT 12221 send EOF dig -t TXT _acme-challenge.shuffleboard01.core.acme.net. @172.16.100.1 <snip> _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT "12221" _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT "111111" _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT "43441" _acme-challenge.shuffleboard01.core.acme.net. 300 IN TXT "12345" so that TSIG stanza posted in Advanced -> Global Settings. Is being ignored.

@Gertjan Thanks for the suggestion, but I unfortunately have no way to try this right now because I'm running CE 2.7.2. I see it's also in CE 2.8.0, but my test system running that version is virtual, so I won't be able to try it until I upgrade my main system to 2.8.0, which won't be until it gets released.

@lef Check if unbound is listening on 127.0.0.1 (and ::1) etc : [25.03-BETA][root@pfSense.bhf.tld]/root: sockstat | grep 'unbound' unbound unbound 45089 3 udp6 *:53 *:* unbound unbound 45089 4 tcp6 *:53 *:* unbound unbound 45089 5 udp4 *:53 *:* unbound unbound 45089 6 tcp4 *:53 *:* ..... This means : unbound listens on all activated interfaces, this includes the two "localhost". This is the default unbound (resolver behavior) : [image: 1748255802423-72425bdd-a09d-49ab-9e33-aadf1514ba9a-image.png] And, sorry, have to ask : firewall rules aren't blocking DNS traffic ? ^^

The 600 sec came from an ISP DHCP server. After I studied logs and SIEM events it turned out that the crash was caused by some sort of DDoS. Just before the crash occurred, there were plenty of blocked ingress WAN packets coming from multiple malicious or suspective IP-adddresses as tagged by Virustotal. So, eventually this might have been a "normal DDoS" and not a pfSense software problem.

@ajperson1927 Are your locations not separated clearly in the public DNS? Just to start, I'm trying to get firstlocation.example.com working within the first location. I have created a domain override in the DNS resolver. A domain override means, that DNS request for firstlocation.example.com are forwarded to the stated IP address. You will need to create host overrides for this.

I had the same issue, several of my device went poof with their static IP and when I see the DHCP logs this what shows me. WARN [kea-dhcp4.alloc-engine.0x3088dc017b00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 xx:xx:xx:xx:xx:xx], cid=[ff:3e:43:3a:49:00:02:00:00:ab:11:35:39:77:96:62:6d:b5:73], tid=0x98a5560c: conflicting reservation for address 172.16.0.4 with existing lease Address: 172.16.0.4 Valid life: 7200 Cltt: 1747537583 Hardware addr: xx:xx:xx:xx:xx:xx Client id: ff:3e:43:3a:49:00:02:00:00:ab:11:37:60:a1:7d:6d:07:47:d8 Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none) Yeah that assigned it a different IP address for a reason that it had conflicting IP address. went back the ISC because of this. I hope the upcoming 2.8 have a fix for this.