Need Help with Domain Trusts between Similar IP Subnetted Sites

I'm working with a new parent company on trying to establish a trust between our two domains.  (DomainA.com - parent company, DomainB - Our company) and I suspect we have a big problem.  Both companies (prior to my time here) have 192.168.1.X as their subnets.  Both have 192.168.1.3 as one of their DC/DNS servers.  

It's my understanding that DNS needs to be working to resolve names between sites before we can establish the trust.  We used a sonicwall to establish a tunnel between sites where in 172.16.X.X is used to translate addresses, such that my 192.168.1.1 is their 172.16.1.1.

Is this even a doable scenario, to get to DNS resolution and ultimately a trust between domains, or will we need to readdress the IP schemes?

If they ping a server on my network, it won't work if it responds with a 192.168.1.x address given they use that scheme on their side.
Taylor HuckstepSenior Director, ITAsked:
Who is Participating?
 
Matty-CTConnect With a Mentor Commented:
1,000. Ouch. I have a number of manufacturing customers and some of their equipment is old and not easily modified without causing unintended consequences so I can understand your plight! That's way too many nodes to "bang out" in a weekend. I'll bet there are client PCs with statically defined network printers/plotters too and maybe even hosts files. But, there is always a way forward. Off the cuff, I think what I would do at DomainB is to create a VLAN. Say VLAN2. Depending upon your model of SonicWall you can do this as either a subinterface or as a separate interface. Or do this on a layer 3 core switch as the next hop from the SonicWall. Give it a 10.0.0.0/8 or /16 network address range of your choosing, and configure the traffic rules. Then, assuming you have smart/managed switches, you can tag the new VLAN throughout your network infrastructure. What is nice about this is you can then move department by department, or floor by floor (whatever works) and renumber devices and then tag the appropriate switch ports to the new network. If the routing is setup properly at the core switch/SonicWall, both subnets will know how to talk to each other. You can then slowly chip away at the old network without having to do it all at once.

On the new VLAN2 network you can create your DHCP pool as you want and it won't "bleed" over to the old VLAN1. And, for the VPN traffic to DomainA, you only have to add 10.0.0.0/8 to the allowed networks (with a little tinkering) and all should flow. I've done this on legacy networks and it all worked although it did take time and testing along the way.

If you haven't used VLANs before, once you get your head around the concepts and possible configurations it's relatively easy and really a brilliant way to segment and deploy networks. This is also a good excuse to get rid of cruddy old switches and replaced with shiny manageable models. Am I speaking Greek in regard to the VLAN technology?
0
 
Cliff GaliherCommented:
You need to change one of the sites. There are enough MitM mitigation that even odd NAT rewrites won't work as expected.
0
 
Matty-CTCommented:
My feeling is that if this is going to be the beginning of a "long and beautiful friendship" (as Rick says at the end of Casablanca) the best solution is to create a solid network foundation between the two networks using the correct rules of IP networking rather than make some Rube Goldberg solution to trick the two networks into communicating. That means renumbering one of the networks. Renumbering is never a procedure that anyone relishes doing but with planning and good communication with management and staff it doesn't have to be a nightmare. Off the cuff, how many hosts would you estimate are on DomainB? Are most hosts using DHCP? If you have a decent downtime window it really isn't so bad to do if it is thought out thoroughly.

Matt
1
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
Andy BartkiewiczNetwork AnalystCommented:
Well in this case I think you have three options
A. Each company has their own DNS server so you can address servers correctly from the perspective of each company.
B. You can create additional vlan(s) that are unique to both companies and place shared resources on these new vlans.
C. Come up with a new IP addressing scheme and basically start over.
0
 
footechCommented:
When changing the IP scheme, I would suggest using a range that is not generally used by home networks.  Consumer equipment favors 192.168.0.x and 192.168.1.x (I think I've also seen 192.168.100.x).  This will help to avoid any issues with clients on those networks connecting in via VPN.
1
 
Taylor HuckstepSenior Director, ITAuthor Commented:
Yeah, the first thing I suggested when I got here was that we move away from a Class C to a Class A network.  We're now paying for the sins of those that have gone before.  

Sadly we are an old manufacturing company and there is a lot of old equipment that has to be touched.  In addition, the same guys who thought it brilliant to use the default Class C IP scheme also fought me on using static reservations rather than manually touching equipment.  So there is a LOT of statically assigned equipment in the building.  Could be 1,000 nodes with addresses.
0
 
Blue Street TechLast KnightCommented:
To add onto Footech's comment, I like to use the 10.x.x.x addressing space as it allows you great flexibility and provides the ability to identify locations or companies if you designate the second or third octet to them. For a smaller company example: 10.10.0.0 = company A, 10.20.0.0 = company B, 10.30.0.0 = company C, etc.
0
 
Blue Street TechLast KnightCommented:
...that we move away from a Class C to a Class A network.  
I'd move away from classful addressing to CIDRs (Classless Inter-Domain Routing).

In addition, the same guys who thought it brilliant to use the default Class C IP scheme also fought me on using static reservations rather than manually touching equipment.  So there is a LOT of statically assigned equipment in the building.  Could be 1,000 nodes with addresses.
Yup, DHCP Reservations are a Best Practice...you should NOT manually assign IP addresses outside of specific servers & NCPI (Network-Critical Physical Infrastructure) that, by design, require manual assignment. 1,000 nodes can be done and the management benefits will be awesome once converted. I wonder how many IP conflict errors have occurred over the years due to manual assignments.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
What I meant was using a 10.x.x.x class A private networking scheme.  We are currently using 192.168.1.1/20 on our side.  On the parent company side they have standard /24 subnets.  But it's also using 192.168.1.1.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
Is it possible to set up a 10.20.0.0 DHCP scope in windows (and obviously turn off the old 192.168.x.x DHCP scope) that allows all DHCP Recipients to ping/talk to the old 192.168.x.x network so that we can do a simultaneous migration?  Set up DHCP first, then start setting up static reservations for everything we can and slowly move every device over to the new subnet?  We're using SonicWalls.
0
 
Blue Street TechLast KnightCommented:
If you configure sites and services within the DC's, and make the networks talk to each other, I don't see why not.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
I'm roughly familiar with VLAN technology, but no expert.  I've managed Cisco switches at a low level in the past, changing ports to different VLANS depending on the task.  I've not set up a SonicWall to help manage two VLANs but that sounds exactly like what we need to do.  I want to reIP everything but as you said "on a department by department" basis.  

You were correct in that there are hundreds of static addresses all over the place, and going to find places I don't have legacy passwords to get in and even change IPs, so it will be a challenge, but if we can do it slowly, it's manageable.

Right now our DHCP is hosted on a Windows server.  Can Windows handle DHCP for multiple VLANs?  I think one of our biggest challenge will be the fact that we don't have a great switching infrastructure to designate VLANs.  I will do a little more research.  Thanks for the direction, and confirmation from everybody that it's not going to work well with duplicate subnets between sites.
0
 
Blue Street TechLast KnightCommented:
Can Windows handle DHCP for multiple VLANs?
Yes!

I've not set up a SonicWall to help manage two VLANs but that sounds exactly like what we need to do.
What is the model of your SonicWALL? You definitely need to make sure it is robust enough to handle a Collapsed Core Topology, which is what you will migrate into if the SonicWALL manages the VLANs. How many users is it supporting? Do you know how many connections are roughly occurring daily?

What are the make/models of your switches?
0
 
Matty-CTCommented:
Again, all it takes is some reading and practice. I'm most familiar with HP ProCurve networking but Cisco, of course, does it all as well. Much of the nomenclature is similar in the CLI except Cisco uses some different terminology with VLAN tagging/untagging. As for DHCP, just to add to Blue Street Tech's comment, it's accomplished by what is called IP helper-address statements in the VLAN ip config.

Basically it's a command that tells all DHCP clients in one VLAN (say 192.168.2.0) to get DHCP addresses for that subnet from the DHCP server at 192.168.3.10 on another VLAN network. Then on the DHCP server you create a scope with the 192.168.2.0/24 network (with appropriate gateway settings) even though the server is on the .3.0 network and it magically works if it is setup correctly.

If you have the time and equipment, the best thing to do is to try it out in the "lab" first.

You can definitely pull off the network renumber if in the long run it is important to have these two networks interoperate. However, getting there will take time and patience. It will certainly go easier if you can get all your switches from one manufacturer and model range so the networking commands and interfaces are identical. As long as senior management understands that there is no magic wand to pull this off, and you get the buy in from them, I say it shouldn't be too hard to pull off. It'll certainly be a learning experience. Once you get one small department done successfully the rest should go easier and quicker!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.