Server 2019 - Active Directory

[BillyCarpenter]

Here's the backstory. I have a client that is switching over to a VOIP phone system. They(phone company) ran some tests and determined that there was double natting. I had never heard of this but got up to speed after doing a little research.

This was an existing network that I took over and it turned out that the last IT guy had installed a Linksys Router and natting was enabled.

The servce provider router is on this subnet: 192.168.0.xxx

The Linksys router has this subnet: 192.168.1.xxx

The server was on 192.168.1.xxx

The router needed to come out because it wasn't needed and it was creating a problem.

So, I pulled the router.

Here's where it gets interesting: I had to change the ip address on the domain controller to the subnet of the service provider router. I then had to adjust the DHCP server accordingly.


Everything is working fine. Or so I thought. This morning I tried to open Users and Computers and it won't open.

I read up on this problem and will be going back tomorrow.

Anyone have any experience with this?

[BillyCarpenter]

Re: Server 2019 - Active Directory

PS - FYI - Double natting doesn't cause a problem when trying to get out to the internet or accessing anything internally. The probem arises when someone has to get into the network from the outside. Or so I was told.

Edit: To be clear, double natting causes a problem with quailty of call on VOIP systems.

[rthonpm]

Re: Server 2019 - Active Directory

If you are running straight from the ISP router/modem, make sure that your internal DNS is still pulling from your domain controller. Active Directory relies on DNS for almost every service and if you're getting DNS information from the ISP, it doesn't know anything about your internal network.

Depending on what's giving out DHCP, it also needs to be pointing at the domain controllers for DNS: never, let me repeat this, NEVER use external DNS servers in an Active Directory environment. Your domain controller(s) should be handling DNS and forwarding external queries to pre-configured external DNS servers.

Also check your IPv6 settings: often without that extra NAT you can get IPv6 information from the ISP instead of just link local addresses, which also screw up your name resolution.

Depending on what software, if any, needs to be installed in the AD environment you could potentially let the VOIP system live off the ISP router, while leaving the AD instance behind the second NAT. I have a few customers doing something similar and other than making sure the VOIP and computer networks are clearly labelled at the wall and network closet, it works pretty well.

[BillyCarpenter]

Re: Server 2019 - Active Directory

If you are running straight from the ISP router/modem, make sure that your internal DNS is still pulling from your domain controller. Active Directory relies on DNS for almost every service and if you're getting DNS information from the ISP, it doesn't know anything about your internal network.

Depending on what's giving out DHCP, it also needs to be pointing at the domain controllers for DNS: never, let me repeat this, NEVER use external DNS servers in an Active Directory environment. Your domain controller(s) should be handling DNS and forwarding external queries to pre-configured external DNS servers.

Also check your IPv6 settings: often without that extra NAT you can get IPv6 information from the ISP instead of just link local addresses, which also screw up your name resolution.

Depending on what software, if any, needs to be installed in the AD environment you could potentially let the VOIP system live off the ISP router, while leaving the AD instance behind the second NAT. I have a few customers doing something similar and other than making sure the VOIP and computer networks are clearly labelled at the wall and network closet, it works pretty well.

No, I'm not using an external DNS server. You taught me that valuable lesson a while back. lol

I think my problem is that I didn 't update my pointer records and I need to flush the DNS cache. Does that sound right?

[slimslob]

Re: Server 2019 - Active Directory

One question, did you check with the ISP to see if their modem could be configured for bridging. That is where the modem puts public address on its output jack(s).

My dentist put in a VOIP system about 8 or 10 years ago that also tied in with their dental software. Worked fine until AT&T had to replace the 2-wire modem that had worked fine for years with a U-verse DSL modem and had them remove the router. Not only that but they assumed that everything was getting DHCP from the router and changed the subnet from 192. to a 10. The problem was that nothing was using DHCP. The dental software required fixed for all the computers (licensing) and the VOIP software required fixed IP for all the phones. The support people at the dental software told me how to reconfigure the U-verse for bridging. Worked fine until AT&T updated firmware, which they did regularly. They ended up changing to cable service.

[rthonpm]

Re: Server 2019 - Active Directory

No, I'm not using an external DNS server. You taught me that valuable lesson a while back. lol

I think my problem is that I didn 't update my pointer records and I need to flush the DNS cache. Does that sound right?

Check everything in terms of DNS, make sure that there's nothing pointing back to the old IP range. DNS should flush itself at the client side fairly regularly, but also double check ipconfig /all from a couple of client machines and servers. You probably need to re-create any manually created A records in DNS, as well as clear out any old records that point to the old IP. PTR records are reverse lookup records and creating new A or CNAME records will also create the associated PTR record as well.

Make sure that there's nothing in the Connection specific DNS suffix search list other than the AD TLD. If there's anything else there, especially the ISP TLD, then you're getting DNS settings from somewhere else and it can be a bit of a bear to track down. Also make sure that DHCP is assigning everything correctly in terms of local DNS servers. If necessary, charge the customer to put a Windows DHCP server in the environment so that the router isn't trying to impose its own settings on anything.

You can also check and make sure that clients are correctly reporting to DNS by running ipconfig /registerdns on a few clients and see if the correct records appear within 15-20 minutes.

Also trying a simple nslookup and a static hostname can help you see just where systems are looking for their name registration.


Some basic sanity checks are also available here: So you want to change your IP range? – Ace Fekay

The article is a little old, but the basics of everything are still valid, especially when considering the Global Catalgoue settings of AD and making sure they're right.

[BillyCarpenter]

Re: Server 2019 - Active Directory

One question, did you check with the ISP to see if their modem could be configured for bridging. That is where the modem puts public address on its output jack(s).

My dentist put in a VOIP system about 8 or 10 years ago that also tied in with their dental software. Worked fine until AT&T had to replace the 2-wire modem that had worked fine for years with a U-verse DSL modem and had them remove the router. Not only that but they assumed that everything was getting DHCP from the router and changed the subnet from 192. to a 10. The problem was that nothing was using DHCP. The dental software required fixed for all the computers (licensing) and the VOIP software required fixed IP for all the phones. The support people at the dental software told me how to reconfigure the U-verse for bridging. Worked fine until AT&T updated firmware, which they did regularly. They ended up changing to cable service.

I contacted their ISP and was told that I can NOT even log into the router. They said that all ports are open (except for a few known security risks) and that's it. I was surprised by that. I have a U-verse router and can log in and makes changes.

NOTE: I think I may have forgotten to point the DNS server back to itself. It's probably still pointing to the old IP address. I'll check that out today. I have the keys to the place.

[BillyCarpenter]

Re: Server 2019 - Active Directory

Check everything in terms of DNS, make sure that there's nothing pointing back to the old IP range. DNS should flush itself at the client side fairly regularly, but also double check ipconfig /all from a couple of client machines and servers. You probably need to re-create any manually created A records in DNS, as well as clear out any old records that point to the old IP. PTR records are reverse lookup records and creating new A or CNAME records will also create the associated PTR record as well.

Make sure that there's nothing in the Connection specific DNS suffix search list other than the AD TLD. If there's anything else there, especially the ISP TLD, then you're getting DNS settings from somewhere else and it can be a bit of a bear to track down. Also make sure that DHCP is assigning everything correctly in terms of local DNS servers. If necessary, charge the customer to put a Windows DHCP server in the environment so that the router isn't trying to impose its own settings on anything.

You can also check and make sure that clients are correctly reporting to DNS by running ipconfig /registerdns on a few clients and see if the correct records appear within 15-20 minutes.

Also trying a simple nslookup and a static hostname can help you see just where systems are looking for their name registration.


Some basic sanity checks are also available here:

The article is a little old, but the basics of everything are still valid, especially when considering the Global Catalgoue settings of AD and making sure they're right.

Thanks so much for your help. It's always appreciated. I'll check all of those things.

[BillyCarpenter]

Re: Server 2019 - Active Directory

Update: I have it all straightened out. The A records were screwed up. I fixed that. That's really all that it was as far as I can tell.

[rthonpm]

Re: Server 2019 - Active Directory

Update: I have it all straightened out. The A records were screwed up. I fixed that. That's really all that it was as far as I can tell.

Rule number one in network troubleshooting: it's always DNS.

Sent from my Pixel 6 Pro using Tapatalk

[BillyCarpenter]

Re: Server 2019 - Active Directory

Rule number one in network troubleshooting: it's always DNS.

Sent from my Pixel 6 Pro using Tapatalk

I can see that because nothing is happening without DNS working.


On a sidenote...there's much more pressure working on a server compared to a copier. Simply restarting the server creates a problem.

[slimslob]

Re: Server 2019 - Active Directory

I can see that because nothing is happening without DNS working.


On a sidenote...there's much more pressure working on a server compared to a copier. Simply restarting the server creates a problem.

Quite often you don't need to restart the server. You can often just restart the service(s) that are supposed to be running on the server. As an example, I went to a major account for a problem of some people not being able to print. I noticed almost immediately that the computers that could not print did not have a proper IP address. The bsm2 type local IT was too busy trying to determine which router needed to be replaced to talk to a lowly copier tech. He had been working on the problem about 5 hours. The receptionist had the IT supervisor from Seattle call me. I told him what I had noticed. He said he would remote in and restart the DHCP service. 2 minutes later the receptionist made a PA announce for everyone having network problems to reboot their computers.

[techsxge]

Re: Server 2019 - Active Directory

Ok why did you changed the subnet of your DC in the first place? It would be much better to just create a VLAN for the VOIP Phone System? Phone Systems are known for being a good entry point as there often is weak port filtering so having it in a different net would not even be that bad. You could then use a dect base to "spread" the phone system to all wireless phones.
For double natting issues you should use a custom firewall and not some build in crap from routers.

Also i am confused by what you need help with:
- AD like mentioned in the title?
- Trouble opnening C&U?
- Access to the service router?

[BillyCarpenter]

Re: Server 2019 - Active Directory

Ok why did you changed the subnet of your DC in the first place? It would be much better to just create a VLAN for the VOIP Phone System? Phone Systems are known for being a good entry point as there often is weak port filtering so having it in a different net would not even be that bad. You could then use a dect base to "spread" the phone system to all wireless phones.
For double natting issues you should use a custom firewall and not some build in crap from routers.

Also i am confused by what you need help with:
- AD like mentioned in the title?
- Trouble opnening C&U?
- Access to the service router?

Let's start from the beginning.

Double Nat is a new thing for me. And I'm not 100% sure that putting the VOIP system on a different VLAN would solve the double nat problem the VOIP company asked me to clear up.

As to the problem I was having. I think I was clear in that after I changed subnets, I could not open "users and computers" in Active Directory.

PS - I'm gonna have to think about the VLAN suggestion that you made. That would have been much easier than what I went through.

[rthonpm]

Re: Server 2019 - Active Directory

Let's start from the beginning.

Double Nat is a new thing for me. And I'm not 100% sure that putting the VOIP system on a different VLAN would solve the double nat problem the VOIP company asked me to clear up.

As to the problem I was having. I think I was clear in that after I changed subnets, I could not open "users and computers" in Active Directory.

PS - I'm gonna have to think about the VLAN suggestion that you made. That would have been much easier than what I went through.

Double NAT situations can cause issues with some services like VOIP systems, but there are ways to overcome it. It usually comes down to latency issues. I've used double NAT in a few situations as a poor man's VLAN, or to just quickly segment traffic. For example, for customer equipment that I bring back to the office to configure or repair, I use a separate wireless router and its Ethernet ports to allow internet traffic while also keeping them entirely separate from my own network, even though both networks are connected to the same modem.

The easiest thing in this instance would have been to keep the AD environment behind its own router and setting up the VOIP system off the ISP modem/router. You'd then just have to make sure that the cabling for the phones was clearly distinguished from the computer connections. If you needed a server on the AD side to talk to the VOIP system, you could always dual home it by having an IP on both networks and letting the firewall profiles of Domain and Private filtre your traffic accordingly, or even just allowing the specific ports needed for the system.

You may have been able to make things easier by just increasing the 192.168.0.x network to a 192.168.0.0/23 so that both your 192.168.0.x and 192.168.1.x IP's were valid for the new network. It's easier to change a subnet mask and DHCP to 255.255.254.0 than futzing around with DNS. For some of my customers, I have a 23 network setup just to give them a full block of 250+ static and dynamic addresses.

Sent from my Pixel 6 Pro using Tapatalk