PfSense (DNS, DHCP) + Active Directory | Issues - Seeking Help!
-
Well let me try the wizard thing - maybe its foobar?
So what test are you running that says you fail dns, and what test are you running that says it passes? The first one you did was like the whole suite of tests. While all that matters in your issue was the dns stuff.
Yes you need a PTR record for nslookup to find the name of the IP you have set for your dns. So it does a query for PTR of 192.168.1.30, if there is no record then sure it will come back unknown. That is not really an issue when it comes to your problem, but points to not fully configured dns setup in general. In a full functional dns, all IPs in your network would have a forward (name or A record) and reverse IP to name or PTR record.
As to mine being setup correctly… Dude its not anywhere close to a functional ready for production setup. I did the bare min to try and duplicate your problem.
As to your removing IPv6.. You ran
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255And your still seeing the teredo, isatap and 6to4 interfaces?? What does your ipconfig /all look like?
If you feel I have been of help, then sure just please donate what you want to the freebsd project in my sig. They use to take donations direct to pfsense, but now they just want it to go to freebsd in general. So if you do TIA for that.. But that is up to you, I just hang out here helping when I can because I enjoy helping people, and going over their issues if I don't have any direct experience with said problem I quiet often learn something knew. Many of the thread here are the same thing over and over again.. But now and then something interesting comes up ;)
So it seems you got your issue sorted though which is the important thing. But I will try the wizard when I get a chance. And run the full test.
One thing - there was that one error with your NTP.. Make sure you get that sorted before you go live and put this into production.
-
Well let me try the wizard thing - maybe its foobar?
It's quite possible. I mean, it worked on the Windows 10 machine that was on the SAME subnet, but any computer that wasn't on the same subnet didn't work so I don't know.
Did you end up testing it? No big deal if you didn't.So what test are you running that says you fail dns, and what test are you running that says it passes? The first one you did was like the whole suite of tests. While all that matters in your issue was the dns stuff.
There doesn't seem to be any DNS failures now? At least not with the dcdiag /test:dns. Though the tests I was doing on the other VMs was dcdiag /dnsall.
I've attached a screenshot to show the first commands results.Yes you need a PTR record for nslookup to find the name of the IP you have set for your dns. So it does a query for PTR of 192.168.1.30, if there is no record then sure it will come back unknown. That is not really an issue when it comes to your problem, but points to not fully configured dns setup in general. In a full functional dns, all IPs in your network would have a forward (name or A record) and reverse IP to name or PTR record.
I'll have to look at a video on YouTube to get a better idea.
Or maybe if I end up looking at your AD/DC setup I could grasp it better.As to mine being setup correctly… Dude its not anywhere close to a functional ready for production setup. I did the bare min to try and duplicate your problem.
That may be true but I think you might have a setting or two done that I might be missing.
As to your removing IPv6.. You ran
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255And your still seeing the teredo, isatap and 6to4 interfaces?? What does your ipconfig /all look like?
Yes sir, I ran the command. No, sorry; it does seem to have worked. At least on the server. I will have to run it as well on the workstations now then. isatap is still showing up on my workstation for example.
If you feel I have been of help, then sure just please donate what you want to the freebsd project in my sig. They use to take donations direct to pfsense, but now they just want it to go to freebsd in general. So if you do TIA for that.. But that is up to you, I just hang out here helping when I can because I enjoy helping people, and going over their issues if I don't have any direct experience with said problem I quiet often learn something knew. Many of the thread here are the same thing over and over again.. But now and then something interesting comes up ;)
Lol, well I'm glad that my problem was compelling enough that you took interest in it! I probably wouldn't have been able to fix this otherwise.
One thing - there was that one error with your NTP.. Make sure you get that sorted before you go live and put this into production.
Yes, that's true. I'll have to run the "w32tm /config /computer:<<pdc-fqdn>> /manualpeerlist:time.windows.com /syncfromflags:manual /update" command again that I mentioned in an earlier comment.
</pdc-fqdn>
-
Hi Isuress
I'm adding my 2 cents to this discussion without having read through it in detail (it's just too long…). We seem to be doing something similar to what you are doing.
We have an central AD (Samba) running on let's say 192.168.10.5 in a /24 subnet. Several client networks (192.168.20.0/24, 192.168.21.0/24, 192.168.2x.0/24) each behind a pfSense which connects to the AD subnet through openVPN. After a lot of trying and testing we ended up with a pretty simple setup that works for us.1. AD domain is AD.yourcompany.com
2. on every pfSense we use a domain override for AD.yourcompany.com pointing to the actual AD serverThis way all requests regarding the AD are actually forwarded to the AD. The rest is just treated "normally". No need for specific DHCP DNS settings or host overrides for the single AD DNS entries like _ldpa... etc. Just make sure your AD knows how to get back to the clients by having the corresponding routes in your setup.
I hope that helps...
-
Hi Isuress
I'm adding my 2 cents to this discussion without having read through it in detail (it's just too long…). We seem to be doing something similar to what you are doing.
We have an central AD (Samba) running on let's say 192.168.10.5 in a /24 subnet. Several client networks (192.168.20.0/24, 192.168.21.0/24, 192.168.2x.0/24) each behind a pfSense which connects to the AD subnet through openVPN. After a lot of trying and testing we ended up with a pretty simple setup that works for us.1. AD domain is AD.yourcompany.com
2. on every pfSense we use a domain override for AD.yourcompany.com pointing to the actual AD serverThis way all requests regarding the AD are actually forwarded to the AD. The rest is just treated "normally". No need for specific DHCP DNS settings or host overrides for the single AD DNS entries like _ldpa... etc. Just make sure your AD knows how to get back to the clients by having the corresponding routes in your setup.
I hope that helps...
Hey there! Every little bit of information helps.
That said, me and Johnpoz have already fixed the issue.
It was a pretty long and arduous process as you can see, haha.
That was one of the settings that had to be changed earlier on. There was other stuff in between.
Thanks for the suggestion though :3