PfSense (DNS, DHCP) + Active Directory | Issues - Seeking Help!
-
Hello pfSense forums;
I've brought this issue to you guys before but typically in a very convoluted manner with mountains of text. I've now created an image to sort of help visualize my issue. The image can be seen below.
Network Diagram + Settings + Errors + Testing:
http://i.imgur.com/Rgo7Ccl.pngI've read many threads about this sort of setup. Supposedly it's very do-able as many others have mentioned they have similar setups, but I'm doing something wrong along the way.
I know that it is recommended that the AD/DC should be used as the DNS & DHCP for your network. I don't want to do this method.
I want to use pfSense because IF for whatever reason I need to turn off the ESXi Hypervisor, turn off the VM, do maintenance or what-have-you; I don't want the whole network to go down. I want the workstation computers to still have access to the internet and to see each other.
Also, I want 1 simple interface located in the same place for everything.
With all that said, getting another Windows 2008 R2 x64 server going wouldn't be possible as the company doesn't want to spend anymore money on another license.I am, for example, able to connect the WIN10 VM to the domain. Though when attempting to connect a workstation from a different subnet, it gives me weird results. As you can see in the image, the workstation FINDS the Domain, sees that I have an account and computer listed for that machine; but once it starts to connect it doesn't work.
How should I proceed? What am I missing settings-wise that would be causing this? If there's more information that needs to be provided, just ask ~
Any ideas?
I've worked with a few people in 2 other sister threads on Reddit about this issue but they've seemed to have come to a halt since Thursday/Friday.
It's come down to being a DNS, Routing, and/or settings issue but I can't seem to pin point it.
I've made only a little process on the issue. Mainly with regards to LDAP not cooperating. This has been fixed with the help of Microsoft KB articles and a toll called "PortQryUI".If you need more information or would like a screenshot of something, just ask!
TL;DR: While using pfSense as my Firewall, DNS & DHCP; I'm trying to connect my office workstation computers to my AD/DC. Both of which are on different subnets. With my listed settings, am I missing something or doing something wrong that would cause me to be unable to connect to the domain?
New Sister Threads (Now dead)
https://www.reddit.com/r/PFSENSE/comments/4jyhhe/pfsense_dns_dhcp_active_directory_issues_seeking/
https://www.reddit.com/r/homelab/comments/4jyjsf/rpfsense_xpost_pfsense_dns_dhcp_active_directory/Old Threads
https://www.reddit.com/r/PFSENSE/comments/4ayup3/pfsense_active_directory_setup_also_misc_network/
https://www.reddit.com/r/homelab/comments/4ayxah/rpfsense_xpost_pfsense_active_directory_setup/
https://www.reddit.com/r/PFSENSE/comments/4ishun/pfsense_dns_and_dhcp_integrated_with_active/
-
Why can you not attach your image.. Imgur is blocked here at work..
What are your firewall rules between your segments, did you setup this other network in AD sites and services?
How is it you can not determine if dns or routing? If all your networks are attached to pfsense, its not a routing problem. Unless you have downtream networks and other routers involved. Pfsense will always know how to get to any network its directly attached to. Could be firewall blocking your access to ports sure… Quite possible if you have locked your segments down. Why don't you just log and see what is being blocked if that is the case?
As to dns - not sure how you could not pin that down fairly quickly.. Does what you want to resolve, resolve to the correct IP? If not then sure dns not setup correctly, if it does - then there you go NOT a dns issue.
Maybe there is more info in the drawing? Can not tell without circumvention of company policy, which is 2 seconds to do - but why not just attach it to the thread post??
-
Why can you not attach your image.. Imgur is blocked here at work..
Oh! I didn't even think about that, my apologies. I've since edited the post to include the attachment!
What are your firewall rules between your segments, did you setup this other network in AD sites and services?
Currently there is only one rule on every interface excluding the WAN. And that one rule is to allow all traffic between LAN interfaces.
I've attached another screenshot to show you what I mean.
I know this is probably not good practice but for initial setup, it makes troubleshooting a fair bit easier. I will lock the ports down when I know everything works.Maybe there is more info in the drawing? Can not tell without circumvention of company policy, which is 2 seconds to do - but why not just attach it to the thread post??
Hopefully the newly attached image to OP will have a bit more information!
I highly doubt it's a blocked port. I'm not sure what it could be to be honest.
-
So question for you why are you getting unknown server in your nslookup. Pfsense will always have a dns entry for itself. That sure points to a problem with something misconfigured, like 192.168.2.5 is not really pfsense?
example
nslookup
Default Server: pfSense.local.lan
Address: 192.168.9.253Also do you have IPv6 enabled?
And we are sure your client are ONLY pointing to pfsense for dns… Confused why your handing out all 3 interfaces via dhcp.. Why would you only hand out the IP of the interface in their network.
-
SO sorry for the late reply! Hopefully you're still around! (That said, you seem to be extremely active on the forum so you probably are. Also thank you for the help)
So question for you why are you getting unknown server in your nslookup. Pfsense will always have a dns entry for itself. That sure points to a problem with something misconfigured, like 192.168.2.5 is not really pfsense?
Oh, yeah that's a weird thing I noticed. So the pfSense box is called Cephalon; as you can see from the OP picture.
The domain set under "General Setup" is ad.MYCOMPANY.com (replace MYCOMPANY with the actual name - the same used throughout the network).
The static IPs for the interfaces are 192.168.1.5 (servers), 192.168.2.5 (Office), and 192.168.3.5 (WiFi).
When a device from one of the interfaces connects to the pfSense box, it'll usually use one of those 3 corresponding IPs for the Default Gateway and DNS depending on which interface the device is connected to (Example: office workstation connects to the office interface, it'll use 192.168.2.5 for DNS and Default Gateway).
So for whatever reason, if a device is connected to 192.168.2.5 OR 192.168.3.5 the nslookup shows up as "unknown" but if I statically set the DHCP to push 192.168.1.5 as the DNS to all the clients, the nslookup shows up correctly as "Cephalon.ad.MYCOMPANY.com".For testing purposes (to rule out any missing DNS lookups) I told the DHCP to push all 3 IPs to all the clients regardless of the interface.
I've tried 3 methods thus far.
#1 - Leaving the default assigned DNS and Gateway (whichever interface it's connected to)
#2 - Statically setting all 3 IPs to all clients.
#3 - Only statically pushing the 192.168.1.5 interface as the DNS to clients.None of the 3 settings really seemed to have made a difference though.
While using #2, the nslookup always showed "Cephalon.ad.MYCOMPANY.com" so it worked.
And then #3 worked 'cause it's the main IP. The only caveat to setting #1 is that the nslookup is "unknown", but it still works like the rest do.Also do you have IPv6 enabled?
I have DHCPv6 Relay and server disabled completely on the pfSense firewall. The "IPv6 Configuration Type" for each interface is also set to 'none'.
I originally had IPv6 also disabled on the AD/DC server as it wasn't required but when troubleshooting the LDAP errors I was getting, for WHATEVER reason Windows Server 2008 R2 x64 doesn't play nice when you have IPv6 disabled; even if you're not using it at all. So I re-enabled it and LDAP started working again.And we are sure your client are ONLY pointing to pfsense for dns… Confused why your handing out all 3 interfaces via dhcp.. Why would you only hand out the IP of the interface in their network.
Currently yes. It's setup the way you see it. I can screenshot other settings if you're curious.
Oh! Also, in addition to methods #1, #2, and #3; I also attempted #4 which was to have the DHCP push only the AD/DC IP (192.168.1.30) to see if that would make a difference (it didn't). -
"I also attempted #4 which was to have the DHCP push only the AD/DC IP (192.168.1.30) "
So your issue has nothing to do with pfsense or your domain overrides if you can not get the box to join the domain even when using AD directly for dns. Not sue who told you you needed to have IPv6 enabled for AD to work.. That is nonsense.. There is nothing in AD that requires ipv6. Atleast not from 2012r2 down, I am not sure what they might have changed with 2016.
But it can cause problems if IPv6 gets registered in AD dns, and client has ipv6 that is broken, etc.
Your rules are any any on your firewall for all your interfaces, so this turns pfsense into a router. Your pointing to AD for dns, but you get a dns failure when try and join domain. So that points to a problem with your AD dns.
I would run dcdiag dns tests and see what you get.
https://technet.microsoft.com/en-us/library/cc731968%28v=ws.11%29.aspxAs to your nslookup error, ah your pointing to an IP of pfsense that does not have anything listed for it. I give me other interfaces in pfsense subdomain names.. So for example pfsense.wlan.local.lan or pfsense.dmz.lan so when I do a PTR on an IP I know what segment that is. And can call out any of the specific IPs of pfsense I want based upon the fqdn I use.
-
"I also attempted #4 which was to have the DHCP push only the AD/DC IP (192.168.1.30) "
So your issue has nothing to do with pfsense or your domain overrides if you can not get the box to join the domain even when using AD directly for dns. Not sue who told you you needed to have IPv6 enabled for AD to work.. That is nonsense.. There is nothing in AD that requires ipv6. Atleast not from 2012r2 down, I am not sure what they might have changed with 2016.
But it can cause problems if IPv6 gets registered in AD dns, and client has ipv6 that is broken, etc.
Your rules are any any on your firewall for all your interfaces, so this turns pfsense into a router. Your pointing to AD for dns, but you get a dns failure when try and join domain. So that points to a problem with your AD dns.
I would run dcdiag dns tests and see what you get.
https://technet.microsoft.com/en-us/library/cc731968%28v=ws.11%29.aspxAs to your nslookup error, ah your pointing to an IP of pfsense that does not have anything listed for it. I give me other interfaces in pfsense subdomain names.. So for example pfsense.wlan.local.lan or pfsense.dmz.lan so when I do a PTR on an IP I know what segment that is. And can call out any of the specific IPs of pfsense I want based upon the fqdn I use.
God damn it, I just wrote you another large, detailed reply and then when I went to post; the forums had logged me out for whatever reason… I lost whatever I typed >:(
Give me a second to rewrite everything and I will also quickly run that DNS tests.
God damn it…. >:( >:( >:( >:( -
Not sue who told you you needed to have IPv6 enabled for AD to work.. That is nonsense.. There is nothing in AD that requires ipv6. Atleast not from 2012r2 down, I am not sure what they might have changed with 2016.
Oh! See, I thought the same thing! But apparently that isn't the case. Someone on /r/homelab suggested it and linked a Microsoft KB Article and it worked, lol.
Microsoft KB Article - https://support.microsoft.com/en-us/kb/816103
Reddit Comment Permalink - https://www.reddit.com/r/homelab/comments/4jyjsf/rpfsense_xpost_pfsense_dns_dhcp_active_directory/d3bvpv2
For whatever reason, LDAP did not want to cooperate if IPv6 was disabled.
Once I re-enabled it, LDAP just started to work again like nothing was wrong.
So weird.But it can cause problems if IPv6 gets registered in AD dns, and client has ipv6 that is broken, etc.
I didn't know this, so I will definitely keep that in mind for the future.
That said, IPv6 is enabled on the AD/DC. Disabled on pfSense and disabled on all workstation clients.
There shouldn't be any other IPv6 related issues; hopefully anyway.Your rules are any any on your firewall for all your interfaces, so this turns pfsense into a router. Your pointing to AD for dns, but you get a dns failure when try and join domain. So that points to a problem with your AD dns.
Really? When you open all the ports to LAN device pfSense becomes a router? I wasn't aware of this.
Does this bring up any particular circumstances that I should consider or be aware of in the future?Just as a quick note; as shown in the OP image, the Windows 10 VM who is on the SAME subnet (192.168.1.xxx) is able to connect to and register on the AD/DC with no problems (anymore, lol - LDAP thing).
When attempting to connect to the AD/DC (192.168.1.30) from a workstation computer on a different subnet (192.168.2.xxx) it doesn't work.
What's weird is that the error outputs (as seen in the OP image) the NETBIOS name of the AD (MYCOMPANY) rather than the "ad.MYCOMPANY.com".
Could this mean anything? Or maybe it means that the workstation attempted to look for "AD.MYCOMPANY.COM" but didn't find anything, so it tried the NETBIOS name as well to see if it would work (but didn't) and then outputs the NETBIOS name in the error?If I nslookup "ad.MYCOMPANY.com" from my workstation, I get the correct LDAP information (as seen in the OP Image); so the workstation KNOWS that the AD/DC exists.
I mean, it even confirms that "there is a computer listed for this workstation on your AD, do you want to use it?" and everything but then cannot make the final sync. It's bizarre.I would run dcdiag dns tests and see what you get.
https://technet.microsoft.com/en-us/library/cc731968%28v=ws.11%29.aspxHere are the results of running "dcdiag /dnsall" on the AD/DC machine.
http://pastebin.com/tCy6pc3tAs to your nslookup error, ah your pointing to an IP of pfsense that does not have anything listed for it. I give me other interfaces in pfsense subdomain names.. So for example pfsense.wlan.local.lan or pfsense.dmz.lan so when I do a PTR on an IP I know what segment that is. And can call out any of the specific IPs of pfsense I want based upon the fqdn I use.
Now this sounds actually quite helpful! I didn't know you could do that, haha.
How would I go about setting subdomain names for my other interfaces?
I quickly looked under the pfSense Interfaces tab and the DHCP tab, and wasn't able to find anything points to something like that.
Maybe I'm looking in the wrong place? Maybe I'm looking for the wrong setting name? Or maybe there's a process involved.
For the time being, would it just be better to statically set my 3 interfaces to point to 192.168.1.5 so that the nslookup resolves with "cephalon.ad.MYCOMPANY.com"?
Even though I don't think it makes a big difference at the moment, lol.Anyway, how should I proceed?
This post ended up being even larger than the original one I had wrote, lol. I think the original was more concise. Oh well…
-
Well clearly there is something wrong with your dns setup from that test.
Name resolution for the name _ldap._tcp.MYCOMPANY._sites.dc._msdcs.ad.MYCOMPANY.com timed out after none of the configured DNS servers responded.
You also have ntp issue - which can cause all kinds of issues with auth when time is off between client/server server/server, etc.Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest
That KB article has nothing to do with ipv6 and only mention of it in the article at all is
"Be aware that the LDAP test over UDP may not work against domain controllers that are running Windows Server 2008. One reason for this can be that you have disabled IPv6 on the Domain Controller."
Right after that they link to an article on how to disable ipv6 on 2k8, etc.
.. But here for example is a article that goes over the pain that you can have with misconfigured ipv6 https://windorks.wordpress.com/2014/09/17/the-day-ipv6-broke-my-dc/
Here a thread that has some discussion. While MS recommends it be left on, what they don't come out and say which they should and would love a link to it if I have missed it. While sure you should leave it on, you should also take some time to correctly set it up so it want F with your setup. If you do not have the time for that, then there is nothing that requires it to work.. You sure and the hell are not using homegroups and or directconnect are you? Forcing some to require ipv6 when its just not wide spread as of yet, and sure and the hell was not when 2k8r2 came out.. Nor when 2k12r2 came out back in 2013.. The world is not quite ready for ipv6 as prime time no matter what someone might say, there is to much legacy gear, and to be honest an almost complete lack of understanding of it most of these small shops, shit even in the large enterprise when you try and talk ipv6 you get deer in headlights quite often.
You can for sure disable it. If you take the time to disable it correctly, etc. Be it you might get some errors about it being off doesn't have anything to do with the system actually working. Unchecking the box on your nic for tcp/ip v6 is not disabling it
If your not going to set it up correctly, I would suggest you disable it until such time you can bring up atleast a basic config that does not cause you grief. Set the registry key and there you go.
If you want to be ahead of the game that yes I suggest you study up on ipv6 and bring it up controlled in your environment. But leaving it how it out of the box from MS is nothing but asking for a disaster.. For gosh sake they have 3 different transition technologies on out of the box.. isatap, teredo, 6to4 – wtf they thinking?
But to solve your problem you have to figure out why your failing basic test that I bolded above, and I would highly suggest you setup NTP for your AD correctly..
As to pfsense being a router.. Yeah if your not natting, your not firewalling since you have any any as rules.. All its doing is routing the packets.. If your boxes are trying to discover your domain via netbios, then yeah that is going to fail when your on a different network, since broadcast is not going to work across the broadcast domain boundry. If you want to use netbios names and such with multiple segments then setup wins.
Or just fix why your AD can not even resolve its own name.
-
Well clearly there is something wrong with your dns setup from that test.
Name resolution for the name _ldap._tcp.MYCOMPANY._sites.dc._msdcs.ad.MYCOMPANY.com timed out after none of the configured DNS servers responded.
You also have ntp issue - which can cause all kinds of issues with auth when time is off between client/server server/server, etc.Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest
Yeah, I had noticed it failed some tests. I'm not sure where to start with some of those to be honest.
I'm thinking I might just delete the whole VM and then recreate the AC/DC from scratch to have a clean slate. I've done little to no settings for this server yet so it wouldn't be that much of a loss. At least that way I'll know that it's not a dumb setting I did.
Thankfully I hadn't entered the CD Key for the server for this exact reason! Was only going to enter it once I knew for sure everything worked and was ready to go.That KB article has nothing to do with ipv6 and only mention of it in the article at all is
"Be aware that the LDAP test over UDP may not work against domain controllers that are running Windows Server 2008. One reason for this can be that you have disabled IPv6 on the Domain Controller."
Right after that they link to an article on how to disable ipv6 on 2k8, etc.Yes! That was the important part of the article. Because of that little snippet, I was able to fix the LDAP problem, lol.
While sure you should leave it on, you should also take some time to correctly set it up so it want F with your setup. If you do not have the time for that, then there is nothing that requires it to work.. You sure and the hell are not using homegroups and or directconnect are you?
No, there's definitely nothing currently in our setup using it. It's disabled everywhere; other than the AD/DC.
And no, we're not using Homegroups or DirectConnect :PThe world is not quite ready for ipv6 as prime time no matter what someone might say, there is to much legacy gear, and to be honest an almost complete lack of understanding of it most of these small shops, shit even in the large enterprise when you try and talk ipv6 you get deer in headlights quite often.
IPv6 in theory is great! But to apply it to already existing networks is a bitch.
My understanding is, if you're going to use it; you have to build your network with IPv6 in mind from the start or else it's just a headache.
But with that said, you are correct. I don't really know of anyone that uses IPv6 currently.You can for sure disable it. If you take the time to disable it correctly, etc. Be it you might get some errors about it being off doesn't have anything to do with the system actually working. Unchecking the box on your nic for tcp/ip v6 is not disabling it
If your not going to set it up correctly, I would suggest you disable it until such time you can bring up atleast a basic config that does not cause you grief. Set the registry key and there you go.I'm probably not going to be using it in our setup at all. Though for the time being, I'll just leave it enabled; just in case it wants to mess with LDAP again.
I just want one less thing tho think about, you know? hahaIf you want to be ahead of the game that yes I suggest you study up on ipv6 and bring it up controlled in your environment. But leaving it how it out of the box from MS is nothing but asking for a disaster.. For gosh sake they have 3 different transition technologies on out of the box.. isatap, teredo, 6to4 – wtf they thinking?
I've only briefly read some information about it, and as to why people should be eventually adopting it. That said, we're a very small company. There are absolutely no gains from using IPv6 in our setup as is.
Looks like they're trying to make compatibility protocols for older, poorly designed protocols, lol.But to solve your problem you have to figure out why your failing basic test that I bolded above, and I would highly suggest you setup NTP for your AD correctly..
Yes, I think I'm going to recreate the VM, create the AC/DC from scratch, and then run the dcdiag test again to see if any problems show up straight from the beginning.
As to pfsense being a router.. Yeah if your not natting, your not firewalling since you have any any as rules.. All its doing is routing the packets.. If your boxes are trying to discover your domain via netbios, then yeah that is going to fail when your on a different network, since broadcast is not going to work across the broadcast domain boundry. If you want to use netbios names and such with multiple segments then setup wins.
I currently have "UPnP" enabled and active. There already seems to be a few workstations using it for certain software.
As for NAT, I have the NAT > Outbound set to the default "Automatic outbound NAT rule generation".
Though I haven't explicitly set any rules or have made any ports for it yet as it hasn't been required. We mostly do everything internally.
Coincidentally enough; you mentioned it in an earlier comment – within the "Status / UPnP & NAT-PMP" on pfSense, there are multiple 'Teredo' rules that seem to have been generated.
Not sure what they apply to though. I've seen those on my pfSense box at home as well.At home, I use "Hybrid Outbound NAT rule generation" because I was having problems getting a game server to work. (Not that that's important for what we're doing now; but just thought I'd throw that in there, lol.)
I don't necessarily want the workstations to use NETBIOS, I was just asking about an assumption as to why the NETBIOS name was showing up in the error.
That said, I don't think I want to setup a WINS server?
From what I've read online as of the last few years, WINS is old and highly deprecated; sysadmins don't recommend using it anymore on newer systems. The only reason a company should be using it is if they have legacy equipment that is already in production that requires it. Or something along those lines. I've never used it myself but if that's what the stipulation is, then I'd rather not, haha.Or just fix why your AD can not even resolve its own name.
I'm not sure as to why it failed that test. If I do nslookup on the AD/DC itself, it finds everything correctly. Weird errors…
Man, these are getting quite long, haha. I'm sorry in advance dude! I know a lot of people hate walls of text.
Once again, thank you for the help and troubleshooting. -
"you have to build your network with IPv6 in mind from the start or else it's just a headache."
Not sure where you got that idea from. Yes your devices need to support it to use it, but its not hard to map your current ipv4 networks to a ipv6 segment. You just use /64 on all your different segments is all. I run multiple ipv6 segments at my house, and I sure didn't plan or care anything about ipv6 when first setting up the network. I just run it on a few segments for testing, its only active on a couple of machines that I use to test when there are ipv6 related questions that I am trying to help with.
I agree it is the path going forward, and I wish more companies would jump on board with it. But sadly its a slow painful process. I for example host up a server in the ntp pool, and serve up both on ipv4 and ipv6. And I have all my vps that supported available via ipv6. I can vpn into my home network get a get a ipv6 address, so that makes it possible for me to test stuff with ipv6 even when in an environment that doesn't support it.
But sad to say its not really ready for prime time imho. And until such time there only resources on the net that you can only get via ipv6 the push towards it going to be slow. Now for example if you could only get to facebook or amazon via ipv6 then shit yeah every consumer would be screaming at their isp for isp support, etc.
"within the "Status / UPnP & NAT-PMP" on pfSense, there are multiple 'Teredo' rules that seem to have been generated."
Why do you have UPnP enabled? See there is something punching a freaking whole in your firewall to use ipv6 via a teredo network through your ipv4 network.. I would be quite concerned with that to be honest. Thought you said it was disabled on all your workstations. So that is your DC doing it? I would suggest if you don't want to disable ipv6, atleast remove the transition stuff, you can use netsh to remove teredo, isatap, 6to4 and just have your dual stack running.
As to wins I agree, it shouldn't be used unless you have some need that you can not work around. Like yes an old application.
If you have no issues from starting over with your DC.. Sure why not - why are you running 2k8r2 if this new play setup. Why not 2k12r2? 2k8r2 is mainstream supported ended beginning of last year did it not?
-
Not sure where you got that idea from. Yes your devices need to support it to use it, but its not hard to map your current ipv4 networks to a ipv6 segment. You just use /64 on all your different segments is all.
I more so mean in a enterprise-level environment that has 500+ workstations and a lot of server hardware. Where downtime isn't really something possible. Adding IPv6 to an existing environment of that size would be pain, no?
I agree it is the path going forward, and I wish more companies would jump on board with it. But sadly its a slow painful process.
I can vpn into my home network get a get a ipv6 address, so that makes it possible for me to test stuff with ipv6 even when in an environment that doesn't support it.But sad to say its not really ready for prime time imho. And until such time there only resources on the net that you can only get via ipv6 the push towards it going to be slow. Now for example if you could only get to facebook or amazon via ipv6 then shit yeah every consumer would be screaming at their isp for isp support, etc.
That is a very good point. Once the major companies start to advocate the use of IPv6, we'll start to see a growth in the market. Don't know how long that'll be though. That said, regardless of whether or not IPv6 ever takes hold, anyone who hosts any sort of network related platform will HAVE to keep supporting IPv4 basically for the loooonnng foreseeable future. There's just WAAAYY too many devices that rely on it. That's life I suppose.
It's like how some airports and banks STILL use DOS based systems.
It's crazy.Why do you have UPnP enabled? See there is something punching a freaking whole in your firewall to use ipv6 via a teredo network through your ipv4 network.. I would be quite concerned with that to be honest. Thought you said it was disabled on all your workstations. So that is your DC doing it? I would suggest if you don't want to disable ipv6, atleast remove the transition stuff, you can use netsh to remove teredo, isatap, 6to4 and just have your dual stack running.
I suppose I don't have a GOOD reason as to by UPnP is enabled. I just have it on for compatibility sake. As it seems, there are 1 or 2 programs that are using it at the moment. If it really is that bad, I figure the alternative would just be to port forward the ports that the programs on the UPnP are requesting. But that's a problem for another day.
When I say disable, I mean I've just unticked IPv6 in the Ethernet Properties panel. I wasn't aware there was further steps involved in removing the use?
I will look into netsh to stop teredo; thank you, sir.If you have no issues from starting over with your DC.. Sure why not - why are you running 2k8r2 if this new play setup. Why not 2k12r2? 2k8r2 is mainstream supported ended beginning of last year did it not?
I don't mind doing it, only because I've done very little settings changes since I've deployed it. So little that it would be MORE work /not/ to just remake the VM. Remaking gives a clean slate in trying to figure out what the hell is going on, haha. I will definitely post back when I have it going and if other weird problems occur. Which, knowing my luck, will most definitely occur, lol.
I'm using Windows Server 2008 R2 x64 because that's the license we have available here at work. If it were up to me, I'd prefer to use Windows Server 2012 R2 x64. I use it at home and it's significantly cleaner than that of WS2008R2. Management would prefer not to incur unneeded costs if it CAN be done with 2008; so I at least have to put up a fight to try and get this to work.
I asked for price on 2012 from one of our vendors and it's like $600+ CAD for just 1 license. So expensive! Even just for a small business. It's crazy. -
If you have no issues from starting over with your DC.. Sure why not - why are you running 2k8r2 if this new play setup. Why not 2k12r2? 2k8r2 is mainstream supported ended beginning of last year did it not?
So I deleted the old VM and recreated the Windows Server 2008 R2 x64 VM. I then recreated the domain, add the 3 subnets, added the 3 reverse lookup zones, and changed the Site name to the company. Tried connecting to it; it still didn't work. I ran the dcdiag /dnsall command again and got more or less the same results.
I decided that I would TRY test to see if Windows Server 2012 R2 x64 would maybe give me better results. So I spun up a VM, ran the domain installer and wizard, add the 3 subnets, added the 3 reverse lookup zones, and changed the Site name to the company.
Tried connecting to the 2012 server I STILL couldn't connect to it.
I ran the dcdiag /dnsall command again and the results were also somewhat the same. The results can be seen below.
http://pastebin.com/qpanNP3nIt looks like no matter the situation, even if I start fresh with a clean install, I get the same errors. Even on different operating systems!
I also ran the "w32tm /config /computer:<<pdc-fqdn>> /manualpeerlist:time.windows.com /syncfromflags:manual /update" command on BOTH servers to repair the time sync thing and it says it was successful. It seems to work for a little but then stops after awhile or after a restart… I don't know what's going on! This is bizarre.NOTE: The 2008 VM is off while working with the 2012 server as to not cause any weird interference.
I'm at my wits end. I'm not sure how to proceed.</pdc-fqdn> -
Well I started a vm up last night to duplicate what your doing.. But I got side tracked. Got the VM up and running, but didn't create the domain.
I don't have a 2k8r2 image I can deploy so that took me a few minutes. But I can spin up a 2k12r2 in minutes.
If I don't get side tracked tonight I will spin these both up. Not sure what your doing wrong.. This really should be clickity clickity.. So I will document what I do, kind of hope run into your same problem so can figure out what your missing. But to be honest unless your leaving out something your doing that is completely wack this really should be click click.
-
Well I started a vm up last night to duplicate what your doing.. But I got side tracked. Got the VM up and running, but didn't create the domain.
I don't have a 2k8r2 image I can deploy so that took me a few minutes. But I can spin up a 2k12r2 in minutes.
If I don't get side tracked tonight I will spin these both up. Not sure what your doing wrong.. This really should be clickity clickity.. So I will document what I do, kind of hope run into your same problem so can figure out what your missing. But to be honest unless your leaving out something your doing that is completely wack this really should be click click.
You are an honest to God saint, haha.
You're actually making a VM JUST to help test this.
All I can say that I VERY much appreciate it man.Yes, from what I've read of the people who've set it up, it was not NEARLY as large a hassle for them as it has been for me.
I don't know what I've done wrong.Maybe I'll give a quick brief of the settings I've changed and whatnot.
pfSense
-
Created Static DHCP entries for all the office workstations.
-
Added the "ad.MYCOMPANY.com" to the Domain under "System > General Setup.
-
Added the IP address of the AD/DC server to the DNS section "System > General Setup".
-
Check ANY ANY Firewall rules for all interfaces.
-
Added 4 Domain overrides for the AD/DC in the "Services > DNS Resolver" section and made them point to the IP "192.168.1.30".
-
Overrides include "ad.MYCOMPANY.com, _msdcs.ad.MYCOMPANY.com, 1.168.192.in-addr-arpa, and 2.168.192.in-addr-arpa".
-
That should be it for the pfSense settings; excluding the ones that were done for the initial setup.
AD/DC Settings
-
Create VM.
-
VM automatically grabs the static IP and DNS from pfSense DHCP.
-
Change power settings to high.
-
Change computer name to "MYCOMPANY-VM-DOMAIN". Restart Guest OS.
-
Add Roles & features - Add Domain Services.
-
Run through installation Wizard.
-
Get Warning about another DNS being used and to create a delegation for the Server within wherever it's pulling the DNS from.
-
Proceed with installation. Complete. Restart Guest OS.
-
Begin DNS installation as it's required for AD/DC to work.
-
Finish/restart.
-
Go to DNS Manager. Create 3 'Primary' Reverse Lookup Zones for "192.168.1, 192.168.2, 192.168.3".
-
Go to Active Directory Sites and Services. Rename "First-default-site" name to "MYCOMPANY".
-
Create 3 subnets for "192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24".
-
Go to Ethernet Properties > IPv4 > change primary DNS to "192.168.1.5" (pfSense) and set "127.0.0.1" as the secondary.
-
Create "Gianluca" user – Add him to Domain Admins group.
-
Create "MYCOMPANY-TECH" to computers.
-
Attempt to connect to AD/DC from workstation on different subnet – "There is a computer "MYCOMPANY-TECH" on the AD/DC, would you like to use it?" Yes – Failed to connect to "MYCOMPANY".
-
Run nslookup on my workstation and point to ad.MYCOMPANY.com – Successful.
-
Run nslookup LDAP test on workstation – Successful.
-
Run 'PortQryUI' to check if all Domain related ports are open, pointing to 192.168.1.30 – everything is open and works supposedly.
-
Run Best Practice Analyzer on AD/DC - ignore backup, redundancy, and scavenging warnings.
-
Run dcdiag /dnsall - a handful of services fail the test.
-
Run CMD as admin - "w32tm /config /computer:<<pdc-fqdn>> /manualpeerlist:time.windows.com /syncfromflags:manual /update"</pdc-fqdn>
-
Nothing works.
-
Whine and complain on Reddit and pfSense forums that nothing works.
-
Drink self into submission.
These are the steps you take to become a successful System Admin, lol. /sarcasm
But yeah, that's more or less everything.Let me know how your tests go! Hopefully my steps were verbose enough. I don't think I missed anything.
If you need to know anything else, let me know. I'll check this thread quickly later tonight just in case you need something for your tests.
I'll then check again in the morning once I get to work. -
-
"Added the "ad.MYCOMPANY.com" to the Domain under "System > General Setup."
Why? But ok.."Added the IP address of the AD/DC server to the DNS section "System > General Setup"."
Again Why? But ok.. Your creating an domain override to ad domain, why do you think pfsense should point to it for stuff it need to resolve extra. It will use the domain override if you just point pfsense to itself"dded 4 Domain overrides for the AD/DC in the "Services > DNS Resolver" section and made them point to the IP "192.168.1.30"."
You should only need the one, the parent domain domain.com"Get Warning about another DNS being used and to create a delegation for the Server within wherever it's pulling the DNS from."
Huh.. why would you think you should create a delegation. This is most likely your problem!!I have to head out in a few minutes.. But yeah creating VMs test and play is the best part about having a esxi host at home ;) It only takes a few minutes to deploy 2k12r2.. I had a 2k8r2 VM that wasn't doing anything. Just removing the domain I had on it, and starting over with a clean creating with a new domain.
Its rebooting now finishing up the removal. But I have to run out for a bit.. I will for sure get it finished up when I get back.
edit: ok so created a domain ad.testdomain.com, added the AD role. Ran through dcpromo - have the screenshots of every step if you want them.
As you can see there is NO ipv6 enabled, the dns test passes without issue.
C:\Users\Administrator.2K8R2>dcdiag /test:dns Directory Server Diagnosis Performing initial setup: Trying to find home server... Home Server = 2k8r2 * Identified AD Forest. Done gathering initial info. Doing initial required tests Testing server: Default-First-Site-Name\2K8R2 Starting test: Connectivity ......................... 2K8R2 passed test Connectivity Doing primary tests Testing server: Default-First-Site-Name\2K8R2 Starting test: DNS DNS Tests are running and not hung. Please wait a few minutes... ......................... 2K8R2 passed test DNS Running partition tests on : ForestDnsZones Running partition tests on : DomainDnsZones Running partition tests on : Schema Running partition tests on : Configuration Running partition tests on : ad Running enterprise tests on : ad.testdomain.com Starting test: DNS ......................... ad.testdomain.com passed test DNS C:\Users\Administrator.2K8R2>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : 2k8r2 Primary Dns Suffix . . . . . . . : ad.testdomain.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : ad.testdomain.com Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter Physical Address. . . . . . . . . : 00-0C-29-99-CC-19 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.9.19(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.9.253 DNS Servers . . . . . . . . . . . : 192.168.9.19 NetBIOS over Tcpip. . . . . . . . : Enabled C:\Users\Administrator.2K8R2>
So I created a domain override on pfsense for ad.testdomain.com pointing to 192.168.9.19
I now have a windows 10 workstation that is on my DMZ network, 192.168.3.0/24 – I created a firewall rule on that zone so it can access anything on 192.168.9.0/24 my lan network.
I click join domain, bing bang zoom bobs your uncle..
To why your domain override isn't working, did you edit unbound to allow it to query out the interface your AD network is on?
What is the ipconfig ./all of your AD DC.. Where is it pointing to for dns? Should be pointing to its own IP. Can it look up its own name?
You need to figure out why your dns test is failing. Did you install DNS before you added the AD role, and try and configure it yourself? This is really bounce through the bouncing ball.
-
Dude check out my edit above. Not sure if you will get notificed on edit.
You say you can query for that record from your client, but it fails the dns test are you actually doing query for SRV or did you create an A record?? I am guessing you didn't let dcpromo create your DNS but you did it yourself?
-
"Added the "ad.MYCOMPANY.com" to the Domain under "System > General Setup."
Why? But ok.."Added the IP address of the AD/DC server to the DNS section "System > General Setup"."
Again Why? But ok.. Your creating an domain override to ad domain, why do you think pfsense should point to it for stuff it need to resolve extra. It will use the domain override if you just point pfsense to itself"dded 4 Domain overrides for the AD/DC in the "Services > DNS Resolver" section and made them point to the IP "192.168.1.30"."
You should only need the one, the parent domain domain.comI've now made changes based on your comments!
I kept the Domain under General Setup; just so that pfSense shows as Cephalon.ad.MYCOMPANY.com.
I removed 192.168.1.30 from the DNS in General Setup.
And then I removed all of the Domain Overrides except for the original override "ad.MYCOMPANY.com"."Get Warning about another DNS being used and to create a delegation for the Server within wherever it's pulling the DNS from."
Huh.. why would you think you should create a delegation. This is most likely your problem!!I don't think I need to create a delegation, the AD/DC thinks it does. When I'm running the dcpromo.exe is says that.
Maybe I'll delete the VM once more and start from scratch to take a screenshot of the error.
From what I understand, it's happening because the AD/DC already has a DNS set from the pfSense DHCP so it's saying "to make sure I make a delegation on pfSense" or something of that sort. I'll screenshot it if I can.I have to head out in a few minutes.. But yeah creating VMs test and play is the best part about having a esxi host at home ;) It only takes a few minutes to deploy 2k12r2.. I had a 2k8r2 VM that wasn't doing anything. Just removing the domain I had on it, and starting over with a clean creating with a new domain.
Gotta love having your own Homelab :3
Feels good man.edit: ok so created a domain ad.testdomain.com, added the AD role. Ran through dcpromo - have the screenshots of every step if you want them.
I would love to see the screenshots! I think you've already posted them ~
As you can see there is NO ipv6 enabled, the dns test passes without issue.
What process did you go through to disable IPv6?
I typically just uncheck the IPv6 option in the Ethernet Properties but in a previous post, you said that this is not enough.C:\Users\Administrator.2K8R2>dcdiag /test:dns Directory Server Diagnosis Performing initial setup: Trying to find home server... Home Server = 2k8r2 * Identified AD Forest. Done gathering initial info. Doing initial required tests Testing server: Default-First-Site-Name\2K8R2 Starting test: Connectivity ......................... 2K8R2 passed test Connectivity Doing primary tests Testing server: Default-First-Site-Name\2K8R2 Starting test: DNS DNS Tests are running and not hung. Please wait a few minutes... ......................... 2K8R2 passed test DNS Running partition tests on : ForestDnsZones Running partition tests on : DomainDnsZones Running partition tests on : Schema Running partition tests on : Configuration Running partition tests on : ad Running enterprise tests on : ad.testdomain.com Starting test: DNS ......................... ad.testdomain.com passed test DNS C:\Users\Administrator.2K8R2>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : 2k8r2 Primary Dns Suffix . . . . . . . : ad.testdomain.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : ad.testdomain.com Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter Physical Address. . . . . . . . . : 00-0C-29-99-CC-19 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.9.19(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.9.253 DNS Servers . . . . . . . . . . . : 192.168.9.19 NetBIOS over Tcpip. . . . . . . . : Enabled C:\Users\Administrator.2K8R2>
It looks like you just ran "dcdiag /test:dns". I was running the full "dcdiag /dnsall" command.
I suppose I'll have to try that command instead.So I created a domain override on pfsense for ad.testdomain.com pointing to 192.168.9.19
I now have a windows 10 workstation that is on my DMZ network, 192.168.3.0/24 – I created a firewall rule on that zone so it can access anything on 192.168.9.0/24 my lan network.
I click join domain, bing bang zoom bobs your uncle.Wow, I can't believe it was that simple for you! Did you not even have to add the Subnets, change the Site, or add the Reverse Lookup Zones!? It just worked RIGHT after running dcpromo!?
To why your domain override isn't working, did you edit unbound to allow it to query out the interface your AD network is on?
I assume that when you say unbound, you're referring to pfSense's DNS Resolver?
I'll attached a screenshot of my DNS Resolver settings.What is the ipconfig ./all of your AD DC.. Where is it pointing to for dns? Should be pointing to its own IP. Can it look up its own name?
As mentioned in a previous post, the AD/DC has both 127.0.0.1 (loopback) and 192.168.1.5 (pfSense) in the DNS section of the Ethernet Properties.
I've attached another screenshot to show what I mean.You need to figure out why your dns test is failing. Did you install DNS before you added the AD role, and try and configure it yourself? This is really bounce through the bouncing ball.
Mhmm! I ran dcpromo right after running the initial AD Role wizard.
I didn't attempt to make the DNS myself.
Though, as mentioned above; the DNS wizard (dcpromo) does give that warning about zone delegation.Dude check out my edit above. Not sure if you will get notificed on edit.
You say you can query for that record from your client, but it fails the dns test are you actually doing query for SRV or did you create an A record?? I am guessing you didn't let dcpromo create your DNS but you did it yourself?
I'm not sure what you mean. I doubt I created a record of any sort though?
No no, I definitely let dcpromo do it's thing. But there was that delegation error I've mentioned.
I quickly Google search the wording and found someone's else's screenshot of the warning.
It is the third attachment. (Replace the "elmajdal.net" with my "ad.MYCOMPANY.com" and it's the same error)
-
I would suggest you get on a MS forum to fix dns test issue. I only ran the dns portion of the test, because that is what is failing on your setup.
I really don't know what your doing wrong.. Maybe your server has a different IP than you think it does. Why would you have your DC setup as dhcp??
Not sure why you would have both your IP and loopback setup as dns? Back in the day when managed AD for part of my job, we always pointed to the actual IP. We always had multiple DCs and pointed to other DCs in the forest for a DCs actual dns.
I really am at a loss to your issue here. This is really clickity clickity.. You clearly have something wrong with dns if you can not pass the test:dns dcdiag that is for sure. Your going to need to figure that out to solve your problem.
What I can tell you is. in my attempt to duplicate your problem my VM that I used had some basic setting already. IPv6 was disabled, since I had no plans on doing anything with ipv6 and that VM.
Windows disable of ipv6 is a simple reg key.
From elevated prompt
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255
RebootThis will remove all the teredo and isatap stuff.. It still does leave a ipv6 loopback. But other than than ipv6 is gone..
To put it back just remove the key and reboot again
reg delete hklm\system\currentcontrolset\services\tcpip6\parameters\ /v DisabledComponents /fOnce I ran through dcpromo, I made sure the box itself could resolve its own name, A record and that there was a PTR setup for it. I did create the reverse zone, the wizard they call dcpromo didn't seem to do that.
I also validated that my soon to be domain member could resolve its host name, since I had setup the domain override. This failed, but that was because as you see from below I only allowed unbound out my wan, my wan sure couldn't get to 192.168.9.19 where DC dns was running. So enabled it to use wan and lan. Tried my query again from the win10 machine. Bing Bang zoom, bobs your uncle could query A record for my 2k8r2.ad.testdomain.com while using pfsense as its dns. So then went to join it to the domain and yea it worked.
But no I did not have to do any sites or create or anything else. I was attempting to duplicate your problem so I could help figure out what you might of done wrong.
Not sure why people leave unbound (yes the resolver) using ALL Interfaces.. How does it make sense that it would use all interfaces to look up stuff from roots or forward. And why would you want it listening on interfaces that you don't want it listening on.
Mine is setup to only use WAN for outgoing and only listens on the lan side interfaces that I have clients using psfense for dns. For example my guest wifi vlan does not, so unbound does not listen on that interface.
To solving your dns problem, validate that the DC can resolve its own name, where are you pointing dns service on it. Do you have it looking up from roots or pointing to pfsense. If you also have pfsense pointing to back to DC you might have some sort of loop that is causing your problem. Your DC needs be authoritative for its own zones and only either go to roots for unknowns or forward somewhere for unknowns. I setup my DC to forward to pfsense, and not to use root hints for stuff it is not authoritative for.
But until you can get your DC to pass the dns portion of the dcdiag yeah your going to have problems for sure. DNS is HUGE portion of AD.. Without that 100% your going to have all kinds of issues.
If you really can not figure it out.. If you can give me remote access to the DC I can give it a look over.
-
I would suggest you get on a MS forum to fix dns test issue. I only ran the dns portion of the test, because that is what is failing on your setup.
I really don't know what your doing wrong.. Maybe your server has a different IP than you think it does. Why would you have your DC setup as dhcp??
I have ALL the IP of every device in the office statically mapped on pfSense. I have a record of ALL MAC Addresses used in the building so I just assign an IP to the MAC so that when the computer joins, it's always using the same IP. It makes doing RPD and some other stuff a little easier for me.
Also, with this setup; if I need to change an IP of a workstation or device for whatever reason, I don't have to get-up and walk over to the workstation to change it. I can just change it in pfSense and when the DHCP lease is over it'll get the new IP. It makes mapping IPs around the office easier; at least for me, haha.Not sure why you would have both your IP and loopback setup as dns? Back in the day when managed AD for part of my job, we always pointed to the actual IP. We always had multiple DCs and pointed to other DCs in the forest for a DCs actual dns.
The "Best Practice Analyzer" suggested to do it. Plus, it's there by default. Though I took your advice and changed the 127.0.0.1 to just use the IP of the AD/DC. I think it's technically the same thing but whatever, haha.
I really am at a loss to your issue here. This is really clickity clickity.. You clearly have something wrong with dns if you can not pass the test:dns dcdiag that is for sure. Your going to need to figure that out to solve your problem.
Okay so, it's weird.
Back on the older VMs, I would specifically run dcdiag /dnsall. With this new VM, I attempted to run the command which you did which was dcdiag /test:dns. According to Microsoft KB, they are actually the same command! But when I ran your version of the command on the VM, it passed all the tests! The results were completely different though. As you can see from the Pastebin links I had sent you before, the test is VERY long. The test that your command runs is significantly shorter for whatever reason.
Microsoft KB Article: https://technet.microsoft.com/en-us/library/cc731968%28v=ws.11%29.aspxWhat I can tell you is. in my attempt to duplicate your problem my VM that I used had some basic setting already. IPv6 was disabled, since I had no plans on doing anything with ipv6 and that VM.
Windows disable of ipv6 is a simple reg key.
From elevated prompt
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255
RebootThis will remove all the teredo and isatap stuff.. It still does leave a ipv6 loopback. But other than than ipv6 is gone..
To put it back just remove the key and reboot again
reg delete hklm\system\currentcontrolset\services\tcpip6\parameters\ /v DisabledComponents /fI ran the remove command from Elevated CMD, it said it was successful so I rebooted.
I haven't really noticed anything particularly different but it seems to work?Once I ran through dcpromo, I made sure the box itself could resolve its own name, A record and that there was a PTR setup for it. I did create the reverse zone, the wizard they call dcpromo didn't seem to do that.
I also validated that my soon to be domain member could resolve its host name, since I had setup the domain override. This failed, but that was because as you see from below I only allowed unbound out my wan, my wan sure couldn't get to 192.168.9.19 where DC dns was running. So enabled it to use wan and lan. Tried my query again from the win10 machine. Bing Bang zoom, bobs your uncle could query A record for my 2k8r2.ad.testdomain.com while using pfsense as its dns. So then went to join it to the domain and yea it worked.
I'm not sure what you mean when you're referring to "A record" and "PTR". From a Google search it seems it has to do with a pointer address?
I'm assuming that has to do with creating entries in the DNS Manager.SO, with some of the things you have suggested thus far, I attempted to connect to the AD/DC using your method and it was successful!
This was even BEFORE creating the reverse lookup zones!
I created them afterwards just in case.Now I say "your method" because in your screenshots you suggest using "Change" function in System Properties.
This successfully added the workstation to the AD/DC! Even without the name of the computer added to the AD/DC before hand.
TYPICALLY, I would attempt to connect to the AD/DC using the "Network ID" wizard directly ABOVE the "Change" feature.
So I would use the Wizard to connect rather than setting it manual.
WITH THAT SAID, using your method successfully added a workstation to the Domain. Shortly afterwards, out of curiosity I tried using my original method instead using the "Network ID" wizard and it failed to join the AD/DC!
I don't understand why manually setting would succeed, while using the wizard would fail? It's bizarre.
I wonder if this WHOLE TIME it would've worked had I just set it manually rather than just using the Wizard.
I think I would be a little upset, lol.But no I did not have to do any sites or create or anything else. I was attempting to duplicate your problem so I could help figure out what you might of done wrong.
Oh, well technically I did have a site setup in my AD/DC. Though technically it was just the "Default-Site-Name" change to "MYCOMPANY".
For the time being, I think I will leave it as the default instead of changing it, lol.Not sure why people leave unbound (yes the resolver) using ALL Interfaces.. How does it make sense that it would use all interfaces to look up stuff from roots or forward. And why would you want it listening on interfaces that you don't want it listening on.
I have left it the way it is out of ignorance actually.
Things were working so I figured I wouldn't touch it.
If you suggest that I change it to look similar to your screenshot, I could try it?
This is assuming you don't think it would break anything currently working?To solving your dns problem, validate that the DC can resolve its own name, where are you pointing dns service on it. Do you have it looking up from roots or pointing to pfsense. If you also have pfsense pointing to back to DC you might have some sort of loop that is causing your problem. Your DC needs be authoritative for its own zones and only either go to roots for unknowns or forward somewhere for unknowns. I setup my DC to forward to pfsense, and not to use root hints for stuff it is not authoritative for.
When you say "resolve its own name" I assume you mean NSLOOKUP?
I ran that command and the weird thing is, if I do nslookup on the AD/DC it just comes up with "unknown" and then the IP.
But If I type "ad.MYCOMPANY.com" right after, it outputs the same information except with the unknown changed to the correct name, lol.
I've attached a screenshot to show what I mean.I mean, for whatever reason everything seems to work now?
Maybe it was the loopback in my pfSense settings that was making things not work?
Maybe it was the fact I was using the "Network ID" Wizard rather than the manual setup?
I'm honestly not sure why it's working now, haha.
Maybe one of your suggestions along the way did it?I hadn't even added the Reverse Lookup and it worked.
I still haven't added the subnets or changed the site name either and it seems to be good?
I did uncheck the "Root Hints" setting before connecting but I don't think that would been the whole reason.When you say you added pfSense as a forwarder, do you mean under the "Forward Lookup"?
Did you add it as a primary zone or a secondary? Did you have the "Store the Zone in Active Directory" checkmarked or no?
What did you use as a zone name? The pfSense host name or just the IP?
Did you "Allow both non-secure and secure dynamic updates" or no?If you really can not figure it out.. If you can give me remote access to the DC I can give it a look over.
Even though I think it's working now, I would actually very much like to take a look on how you setup your AD/DC!
I can see how things are supposed to be done and maybe I could copy some of the settings to put them into mine correctly.
It's one thing to attempt to visualize what a person is saying rather than seeing it yourself, you know?Once again Johnpoz, I would like to sincerely thank you for your help!
You've gone above and beyond to try and help.
Do you maybe have a donate button? Or would you just prefer I donate to the freeBSD community in your forum signature?