@bmeeks said in Errors transferring zone between Windows Server and pfSense Plus:

@aaronouthier said in Errors transferring zone between Windows Server and pfSense Plus:

DNS resolution to local resources only works on non-windows devices, as they are using pfSense directly for DNS. Everything trying to use the 2 Windows Servers, including said servers themselves, are not resolving local records.

This is because of the way you have chosen to configure your network with regards to DNS.

If you refer to all local hosts on the Windows clients using their FQDN (hostname.domain), and set up your Windows AD to forward lookups for non-authoritative domains to pfSense, then it will work. But using simply hostname without a domain qualifier will not work because Windows AD DNS and the Windows clients will attempt to append the AD domain to the hostname and thus the lookup will fail as it won't be forwarded to pfSense and your other clients' DNS records do not exist in the Windows AD DNS server's database.

I never use hostnames only for services, only FQDNs. this is true for both local and Internet services. Earlier, I added the domain override to point to my primary server, but still no dice.

If you want your non-Windows hosts to be able to resolve Windows clients' IP addresses, then you must configure a domain override pointing to your Windows DNS server for the AD domain and open appropriate firewall rules allowing TCP/UDP traffic on port 53 (DNS).

The only client machine that requires to access services on windows systems is my Windows 11 Laptop.

The windows servers are just test machines. Their sole purpose is for learning. I'm beginning to suspect I have fouled something up by changing DNS settings so many times. I'm going to have my laptop leave the AD Domain, and then tear-down the Windows server VMs so I can rebuild them from scratch.

@DrSKiZZ

I was able to fix it by wiping and re-installing PFsense strangely. I also might've turned off some of those remote management features in the BIOS during the wipe that was turned on before the wipe.

@nobugswanted Use pfBlocker Python Mode for DNSBL. We are aware of this issue and have a solution in the works for 2.8.1

@hydn said in New "settings" tab in 2.8.0:

Enabling registration has any downsides?

One .... it doesn't adhere to KIS concept.
Best practice would dictate :
If you don't need dhcp-into-dns registration, don't activate it.

On the other side : help Netgate testing this new solution : one more user is one more occasion to find possible issues. Many user will thank you later.

For other, we've been waiting for this thing to work for a decade or so.

Yup, and more improvements should possible with the new fast-reload capability.

@aGeekhere

When I read several "unbound access-control-view" I'm pretty certain that "access-control-view:" needs to be placed in a server: block :

server: access-control-view: 192.168.1.100/32 unrestricted_youtube access-control-view: 0.0.0.0/0 restricted_youtube ....

What I'm not sure about : you use IPs fro youtube resources.
This :

local-data: "youtube.com A 216.239.38.119"

might be true for one moment, and the next moment it's another IP, as Youtube uses many (like : a lot) of IPs so they can do load sharing, prtect against DOS, update/upgrade their servers in real time.
And : protect themselves against people that try to limit the access to their services ^^

Sorry to invade the post in this way, but I would like to know if in version 2.8 it is already feasible to switch ISC for KEA, observing who uses 2 pfsense appliances in HA CARP?

@sunni Had the same issue with 2.8.0 I'm guessing since the Comcast-provided gateway IP is not pingable. Seems to be working fine again after disabling gateway monitoring as a workaround.

@4o4rh why doesn't it like match-clients

server:

Define views for each interface subnet

module-config: "iterator"

LAN clients

view:
name: "lan_view"
match-clients: { 192.168.4.0/24 }
local-zone: "net.lan" transparent
local-data: "ipfw.eapenet.lan. 3600 IN A 192.168.4.5"

@mpossari said in Issues starting BIND (DNSSEC) after upgrading pfSense from version 2.7.2 to 2.8.0:

The issue was that the outdated "auto-dnssec maintain" directive was being reinserted by pfSense.

pfSense itself doesn't know what 'bind' is. pfSense doesn't come with bind.
You probably installed the pfSense 'bind' package, and that one pulled in the latest original FreeBSD' bind, and the GUI part so it can work with pfSense.
The issue is : bind - the FreeBSD package itself was updated, but not the pfSense GUI package part that creates the bind config files.
The pfSense bind package maintainer should be informed.

Happened again.

/var/etc/filterdns.conf contains hostnames and table names as expected.

: ps aux | grep dns root 14880 0.0 0.2 20348 9672 - S Fri20 0:11.89 /usr/local/sbin/lighttpd_pfb -f /var/unbound/pfb_dnsbl_lighty.conf root 29469 0.0 0.1 21872 3552 - Is Fri20 0:02.73 /usr/local/sbin/filterdns -p /var/run/filterdns-ipsec.pid -i 60 -c /var/etc/ipsec/filterdns-ipsec.hosts -d 1 root 64743 0.0 0.4 88956 17488 - Is Fri20 0:08.51 /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1 root 14206 0.0 0.1 13040 2656 0 S+ 17:39 0:00.00 grep dns

The table in question has only one IP in it, not two.

"grep filterd resolver.log" shows "Adding Action: pf table:" for the missing hostname.

As above, I had to "killall filterdns" and then Status>Filter Reload to recover.

@hydn Appreciate the heads-up.

In general settings, I’m using Quad9 over DoT. The network uses the DNS Resolver with pfBlockerNG and DNSBL, listening on the network interface addresses. This all works fine.

What I’m now trying to do is to isolate part of the network by using a VLAN and route all its traffic—including DNS—exclusively through the VPN. From a privacy perspective having VPN traffic and DNS within the VPN seems to be the safest approach. I’m fine giving up some control and filtering provided by pfBlockerNG and popular public DNS.

I’m still not quite sure how to set this up properly. I tried configuring the VLAN’s DHCP server to hand out the VPN’s internal DNS IPs (10.2.1.1 and 10.2.2.1) for the 10.10.99.0/24 subnet. It looked like it was working earlier, but now DNS queries are timing out.

I have disabled DNS Resolver on the vlan 99 interface.
The 2 Gateway VPN IPs are used as dns servers on my host /etc/resolv.conf

86bc21ae-69f8-41da-b82e-35ce06810538-image.png

7a22fe03-c791-4d75-8e5c-58fd80df1c49-image.png

nslookup timeout
501415eb-3e40-4f1e-a0e2-d80f1b446853-image.png

Traffic going out from VLAN to VPN DNS
59e063d0-febe-4c03-9e10-a8b6afb26eaf-image.png

traffic seems coming back from the VPN (this is correct as I have 1:1 NAT on 10.2.0.2 to 10.2.1.1)
0b095dd3-f8e9-4b14-a431-1069c9cb85f6-image.png

I suppose on the VLAN I should see traffic response coming in from 10.2.1.1 but I do not and that is why I see "timed out".

The nat seems to work I think. I am confused on why the DNS response is not properly routing back to the client

my 1:1 NAT
217c0de8-17cd-4d0c-81e1-0ef5ba5b32e2-image.png
my outbound
48ab8aed-4cd5-4edb-82b2-78c13dece434-image.png

@Lars_ I ended up creating a patch that fixes the problem for route53-v6. But I attempted to fix the problem for noip-v6 too. Feel free to try it out.

Here's a link to the relevant issue where I attached the patch:
https://redmine.pfsense.org/issues/16249#note-1

You can use the System_Patches package to apply the patch. After installing the package, you can go to:

System > Patches

From there you can click Add New Patch. This will take you to the system_patches_edit.php page. I included a screenshot that shows how to fill in the fields. The "Patch Application Behavior" values are pretty important. You'll want to set Path Strip Count to 1, and set Base Directory to /.

I don't think my patch is a good long term fix. But it might be acceptable as an immediate fix. The problem is the patch just assumes the pfsense device has an IPv4 interface. I'm not accounting for NAT64 and/or other XLAT technologies. I think a better long-term approach would be to:

Try to use IPv6 to reach the Dynamic DNS API endpoint (it should use the newly implemented behavior from pfsense 2.8.0) If step one fails then fall back to using IPv4 or any other available connection. (maybe we need a new configuration setting to allow/force the Dynamic DNS client to use a different interface)

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. :)