pfSense with Server 2019 AD DS and Netgear ORBI (as AP)

bearhntr

BPA is the Best Practices Analyzer tool which is in Server OSes since 2008.

It checks settings and that everything is on the up and up. Some of them are bogus, but a lot are not (like permissions settings for DHCP to update DNS, etc.)

I am getting some ROOT HINT errors with IPv5 addresses, as I have not completely figured out this protocol and set it up properly.

Curtis

bearhntr

@bingo600

OK - so far so good - until - I got here. I tried to enable the DNS resolver and I get an error that states the DCHP server is not enabled in pfSense, after I hit SAVE.

So I have DNS full (well almost) working on the MS Server - see below. DHCP appears to be working and the DHCP relay feature in pfSense appears to be working. Devices in my home are getting an address from MS Server - and even the reservations that I have set are working too.

I have given up (for the moment) using IPv6 - I think I have it working --- then reboot a device and it gets a completely different IPv6 address...even the MS Server which has an RSVP set -- frustrating. But this site did get to 17/20 working ( https://ipv6-test.com/ ). Still need to learn a little more about IPv6 I rekk'n.

So something that is gnawing at me is this point. In my DNS setup on the server. I cannot get the pfSense to resolve a name in the DNS Forwarder setup (for ipv4 -- it would under IPv6, before I turned it all off).

This is what my pfSense looks like.

When I had IPv6 setup with what I thought was a proper format of addresses and went to the DNS Forwarder setup in Windows....I added the STATIC address of the LAN port in pfSense. The name resolved in IPv6, but never has in IPv4 - albeit I get an OF under the validation setting. Which indicates it is working.

Why does it not resolve the name? I am thinking it has something to do with the fact that also cannot PING the LAN port of the pfSense from any of my networked devices.

I appreciate your help so far - and I think I am at about 90-95% there (well more like 85% since I do not have IPv6 working). If there is anything you want to see, let me know. I will get a screen shot.

Maybe once I get all this working - I write a book. LOL

Curtis

bearhntr

@bingo600

How did you do that cool signature? I do not see that anywhere in the profile settings area.

Curtis

bingo600

@bearhntr

Can you resolve external dns names

Ie. 8.8.8.8 to "google"
or "google.com" to ... whatever

I had some issues with the "Unbound Resolver" , when it had to accept RFC1918 responses from my bind9̈́s - It wouldn't by default accept "private ip" responses

I had to add this to the "Customs options" in the bottom
server:
private-domain:"your-domain.ext"

The forwarder is using dnsmasq , so the same options might not work.
I have never used the forwarder.

Maybe @johnpoz have a hint here

/Bingo

bearhntr

@bingo600

I am totally confused by your response.

Resolve the 8.8.8.8 specifically where?

You got pictures of what I should look at?

Curtis

Tzvia

@bearhntr
In your Server 2019 DNS, place a static entry for your PFSense LAN IP~PFSense Hostname. Then the name should resolve from any client that is using your server for DNS. Remember, there is no need to resolve a name from an IP in the Forwarders tab of MS DNS, it doesn't mean it can't be used/isn't reachable/isn't working (shows as OK) it just means it can't find a DNS entry for it.

However, you should be able to use PFSense DNS in resolver mode, not forwarder. I don't get why you are getting a DHCP error message. I'm using Server 2016 DNS/DHCP, and forward DNS to the PFSense box with DNS in resolver and it works well. If unbound craps out, my DNS servers will then fall back to using root hints, so I find it works quite well set that way.

Maybe I missed it here, but I don't think you are using any VLANS- just one internal LAN network? So the MS Server is in the same network as the desktops and the LAN IP of the PFSense? If that's the case, DHCP Relay is not needed/used. Being on a single broadcast domain, (DHCP is a broadcast) the clients can reach your server's DHCP just fine without it. I use it as I have my servers on another VLAN.

bingo600

@bearhntr

I meant if you could resolve those ip addresses on a "Client computer" , using the new setup

bearhntr

@tzvia

You are correct. One LAN network 192.168.10.xxx everything is in that network. Do not think (at this time) I need any VLANS.

I am not sure what you mean to add an entry in my Server DNS for the pfSense -- would not need to be in the DHCP? Where specifically are you referring that I add it. It is almost as if the connection fails because of ICMP (I know that I cannot ping the pfSense LAN port (IP or name).

Call me silly - but I am fanatic about seeing "unknown" - "not found" etc.. Even run the BPA over and over until all messages are gone -- except for those 2 damn ones from MS about not having more than one DNS setup -- maybe at some point I will setup another system on my old HP T610 to be a secondary DNS. LOL And the other message that the loopback must be in the DNS on the AD DS box, just not as first entry. I mean REALLY?!?!? Microsoft - that error has been around 2 decades.

If you got some pics of what you are suggesting - or want a picture of mine. At this point, I have not done anything more with the domain (joining machines to it, etc.) until I get all these 'quirks' sorted.

In the past I let the ORBI handle everything - but when the old DC died, I decided to go pfSense and DC and let the ORBI be my AP....until I eventually move to Ubiquiti UniFi system....which I have been following the forums - appears to be its own nightmare. LOL

I really want to get more abreast with IPv6 as well...as I am considering requesting my own IPv6 address from ARIN (North America).

Curtis

bearhntr

@bingo600

From the AD DS (DC):

From one of my networked computers:

Have not ever had a problem with that once I enabled the DNS Forwarder.

Curtis

Tzvia

@bearhntr
Your Forwarders screenshot shows that 192.168.10.254 DNS server had that green checkmark, which meant that it was visible on the network, but not resolvable to a name. I understand it is set static. BUT it does not appear to have a record in MS DNS, if it did and DNS was functioning correctly, it would resolve to a name. But the more I think about it, the 192.168.10.1 is PFSense, and 192.168.10.254 is the ORBI? If that is still UP (why?) and you want that to resolve to a name, you would need to add a static DNS record for it to the Server 2019 DNS, but frankly, now that I read through this again, that's not what I would do. If you have the DNS running on your Server 2019 box, I would disable DNS and DHCP on the ORBI as soon as MS DHCP is setup and giving out my server DNS to clients. No reason to forward to the ORBI either, unless I am missing something.
How I set mine up is, all the clients point to my two Server 2016 machines- I use MS DHCP, and I set it to provide my two servers as DNS servers, as part of the lease. I then setup DNS to forward to the lan interface of my PFSense box, which I put in resolver mode (I see no reason to forward from PFSense, but you may have a reason to).
So the DHCP scope options:

That points my stuff to my servers. I set DNS forwarding to the PFSense box:

But I set it to also use root hints in case the PFSense DNS (unbound) was borked, so it will just go directly to the internet. Yes, if my servers go down (this is why I have two) I will have no internet unless I manually set the IP info on the client using PFSense as the DNS. I only have the 'standard' version of Server 2016, but that gives me two virtual licenses, so my server box is running Vmware ESXI, and I used both my virtual licenses to create two domain controllers running DNS and DHCP.

bingo600

@bearhntr

As @Tzvia mentions

If you want to resolve the 192.168.10.254 to a name.
That entry must be present in the M$ DNS server.

If you don't use DHCP, but static ip for that entry, you have to enter it manually in the appropriate zone on the M$ server.

/Bingo

bearhntr

@bingo600 and @Tzvia

@Tzvia and @bingo600,

I am still not clear, but maybe I am reading something wrong. Let me see if I can clarify things.

Version 2.5.2-RELEASE (amd64)
built on Fri Jul 02 15:33:00 EDT 2021
FreeBSD 12.2-STABLE

pfSense WAN port is DHCP and DHCP6 and connected to Cable Modem (I get an address on both of them). The v6 address is 2001:558:xxxx:xxxx (it appears to me to be a 128 bit number but I have WAN set to a /64 prefix).

pfSense LAN port is STATIC at 192.168.10.254 and IPv6 is "Track Interface" and pointed to the WAN port. I appear to also be getting a V6 address on that one - but it is 2601:c9:xxxx:xxxx:xxxx:xxxx:xxxx:cb24 (masked - but the last 2 octets appear to be some portion of the MAC address) - whereas the one from WAN does not follow that convention.

pfSense has DNS Forwarder enabled see image - are the settings.

pfSense does not have DNS Resolver enabled - when I tried to enable it I got an error. See images 1 & 2.

pfSense also has DHCP Relay enabled on LAN and the 192.168.10.250 programmed in - as my server is desired to handle all DHCP.

The ORBI is set to AP mode and does no DHCP or DNS at all. It has an RSVP on my Server 2019 Standard machine in the DHCP so that it is always 192.168.10.1 (and the satellite is always 192.168.10.2 - always RSVP). I have a SmartThings HUB which has an RSVP to .3 and a HomeSeer box which is .4. All of these work.

The Server has 2 NICs - but one I have disabled - as it was originally an ESXI box with Server and pfSense both on it. Decided to stand up a separate pfSense box. So ESXi went bye-bye for just Server 2019. It has a Static address of 192.168.10.250 (using 255.255.255.0) and the Gateway is the pfSense LAN (192.168.10.254). DENS entry 1 (is 192.168.10.250) nothing in #2 (it did have 127.0.0.1) - but made no difference in the error I was getting in DNS Best Practice Analyzer. So took it out.

So as it is now. Server is handing out address to anything on my network (1 day lease at the moment). The only device that seems to change addresses is my Samsung S10+ - as it changes its MAC address. My NAS has a Static IP address on it now. As trying to get it to allow AD DS logins would not work with it set to DHCP with an RSVP. (still fighting with that one). LOL

DNS appear to be working, and everything seems to have no issues getting to the Internet. Root Hints seem to resolve also with no problems.

The only issue I seem to have is the FORWARDERS tab in the DNS will not resolve the address of pfSense LAN - but gives me the Green check. Here are some screen shots of the DNS settings. What I guess I do not understand is making an entry in DNS for the pfSense LAN address/name.

I also have a DHCP RSVP for the Server 2019 box in DHCP - just to make sure that its v4 address is always there. There was an issue when I was playing with the v6 stuff - where it switched the IPv4 back to DHCP and not static. Had to hook up a monitor and KB to find out what address it got - so that I could RDP back into it. (that was fun - NOT)

I truly appreciate the help - as I am sure I will get into a bind when I start messing with v6 again.

Curtis

bearhntr

@bingo600 and @Tzvia

I also still do not know why I am getting these -- I have nothing setup for v6 - the NIC is set to DHCP and it seems to be getting an fexx:xxxx address.

I get no other warning or errors in this tool - for anything - just these.

Curtis

Tzvia

@bearhntr Well, it looks from your screenshots like you are trying to enable both the DNS Resolver and the DNS Forwarder sections of PFSense? It's one or the other. Unless you have a need to use a particular external DNS server, like using one with porn blocks or something, the DNS resolver works fine without having to specify anything, resolving to root servers if you choose to forward from your Windows server to it.
No reason to forward to the wireless AP if that is the box at .254 - it shouldn't be doing DNS or DHCP if your Windows Server is handling it so I don't know why it's there. And if you don't have IPV6 setup the server may not be able to resolve IPV6 only root servers, causing that last screenshot (just guessing here)? So first decide if you want to just let your Windows server resolve to the internet or forward to the PFSense box and have it resolve. That's what I am currently doing but I've done it both ways and it seems to make no difference. Once IPV4 is good to go, you can tackle IPV6.
And yes with Windows server, it is best to only pass out your Windows server IP as the DNS server in DHCP scope settings, for Windows clients.

bearhntr

@tzvia

I tried to be as clear as possible. I am sorry if there is some confusion.

192.168.10.1 - ORBI Router (in AP mode only) Does not do anything with DNS or DHCP
192.168.10.2 - ORBI Satellite (in the other end of the house so that my office can have network)
192.168.10.250 - Windows DC1 (Server 2019 Std) to handle DNS / DHCP / AD DS / LDAP
192.168.10.254 - pfSense LAN port

I am guessing that I was thinking DNS Resolver on the pfSense would resolve DNS (like the DC1 box is supposed to (wanting it to) do).

Yes....IPv6 is not configured any more - but just find it odd that the Windows BPA keeps telling me that IPv6 root hints need to resolve. Nothing is setup in IPv6 any longer, but I cannot disable that protocol in the DC - Windows will yell about it. The NIC in the DC does get an IP (see below):

So I still cannot get the pfSense to resolve to a name in the DNS Forwarders setting tab. I always get this:

AS stated - it appears that everything works....but I hate 'unresolved' things. Because I want to get IPv6 going and then start working on VPN stuff for streaming and monitoring as well as other Firewall stuff.

*** Have you ever setup or used an iPerf3 server??? I see that pfSense can be setup to do that. I use the Speed Test WiFi Analyzer - analiti quite often on my FireSticks. I will eventually get CAT6 run throughout the house, but for now...everything except the pfSense, DC1 and ORBI are all wireless.

Thanks again for sticking with me.

Curtis

bearhntr

UPDATE:

OK. I have performed the following:

Disabled DNS Forwarder in pfSense:

Enabled DNS Resolver in pfSense - not sure if all of this is correct - but, I seem to still have Internet:

I am able to ping the pfSense now - but still not resolve a name:

Strange that when I was playing with IPv6 - the IPv6 would resolve the name (this is an old image):

We're getting closer -- I can feel it.

Curtis

bearhntr

After making the changes to the pfSense Resolver vs. Forwarder -- I performed an ipconfig /flushdns and ipconfig /registerdns from ADMIN CMD prompt on the DC.

Waited 10 minutes - which should not have needed - but I am getting this now:

WAAAAAH!!!!

Also - does this look correct? Does the Router Advertiser need to be running?

Curtis

Tzvia

@bearhntr Resolving a name from an IP requires an entry in DNS. So if you want it to resolve to a name just create a static entry for it I Windows DNS. It's green because it responds and frankly doesn't need to resolve to a name. Remember, the names are for US, the IPs are for routing and MAC addresses are for delivery. Ok the 254 IP is PFSense now and you're forwarding to it and it is forwarding to some DNS you set on the general tab. My suggestion, if you don't need to use a specific public DNS, just habit you use DNS from X whoever, just leave it in resolver mode. You don't need to send your internet market usage to those data miners. PFSense will use root servers and resolve without their prying eyes.

bearhntr

@tzvia

OK. Specifically "where" do I need to add this name/IP in the Windows DNS? This I think is where part of my confusion lies.

Now you have confused me with the comment: "Ok the 254 IP is PFSense now and you're forwarding to it and it is forwarding to some DNS you set on the general tab. My suggestion, if you don't need to use a specific public DNS, just habit you use DNS from X whoever, just leave it in resolver mode. You don't need to send your internet market usage to those data miners. PFSense will use root servers and resolve without their prying eyes."

Here is what I have in GENERAL SETUP (this is the DC address):

Curtis

bearhntr

UPDATE:

OK -- By Golly -- I think I have fixed it.

Much thanks to everyone. Now to make the Document for all of this.

Curtis