PfSense (DNS, DHCP) + Active Directory | Issues - Seeking Help!
-
"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?
-
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