Connecting Networks Together

Planning the Connection

When you first glance at the idea of linking two small networks, the instinctive thought is often that a simple patch cable will do the trick. Both LANs are small, the traffic seems manageable, and the job feels trivial. Yet, the reality of IP address management, name resolution, and security policies can turn a straightforward link into a source of headaches if not addressed from the start.

The heart of the problem lies in the way each network operates its own DHCP and name resolution infrastructure. If Network A and Network B each host a DHCP server that hands out IP addresses and a WINS server that stores host names, connecting them without any coordination means that a client may receive a lease from either side. Suppose a machine that belongs to Network A boots up and sends a DHCP Discover. The cable now links the two broadcast domains, and the DHCP request travels to both servers. Whichever server responds first hands the machine an IP address that matches Network B’s subnet and a reference to Network B’s WINS server. The client now believes it belongs to Network B. When it later tries to locate domain controllers or other resources that belong to Network A, it will fail because the name resolution information it carries points to a server that has no knowledge of Network A’s domain controllers.

In a small environment, these issues might be overlooked for months, but as soon as the network starts to grow - adding more users, printers, or servers - the inconsistencies become noticeable. Users might be logged into the wrong domain, or they might see blank network shares. Even more problematic, the duplicate IP addresses can flood the network with ARP traffic, causing a cascade of communication delays.

Another subtle danger is the mixing of security policies. Each network usually enforces its own firewall rules, VLAN segmentation, and access control lists. A direct link bypasses those controls, creating a bridge that can carry traffic from one policy domain into another. An attacker exploiting a vulnerability on one side could easily hop onto the other side without additional safeguards.

Before you plug a cable in, map out the network boundaries. Identify the subnet ranges, DHCP scopes, and WINS servers for each side. Verify that the subnets do not overlap - overlap is the easiest way to create address conflicts. If overlap is unavoidable, consider setting up a DHCP relay or a dedicated gateway that can enforce the correct address space for each client.

Decide whether you need a full interconnection or a limited bridge. Sometimes a single dedicated interconnect is sufficient, but in larger deployments you might need a router or Layer 3 switch to handle routing, policy enforcement, and load balancing. If you opt for a router, ensure it runs the latest firmware and is configured with secure management access.

Security is a critical factor that must be addressed early. Configure the link with a VLAN that is isolated from user traffic if you need to keep administrative traffic separate. Apply ACLs that allow only the necessary traffic - typically DHCP, WINS, DNS, and SMB between the two domains - while blocking everything else. Document these rules so that future network changes don’t inadvertently widen the attack surface.

Finally, plan for future growth. If you anticipate adding more networks later, consider a scalable architecture such as a centralized DHCP server that spans all subnets, or a shared WINS server cluster. These options reduce complexity and make it easier to maintain consistency as the network expands.

Technical Implementation – Setting Up WINS Replication

Once you have confirmed that the networks share the same subnet range and that the DHCP servers are correctly configured, the next step is to ensure that name resolution stays accurate. In a Windows environment, WINS servers hold the mapping between host names and IP addresses. If two networks use separate WINS servers, they are unaware of each other’s hosts, which leads to the resolution failures described earlier. The solution is to make the WINS servers replication partners so that they exchange information automatically.

To begin, open the WINS Manager on the first network’s server. Navigate to the Server menu and choose “Replication Partners.” This opens the Replication Partners dialog box, which is where you will define the relationship between the two WINS servers.

In the dialog, click the “Add” button. Enter the IP address of the WINS server that resides on the other network. By default, the new partner is configured as both a push and pull partner. This means that each server will periodically send updates to the other (push) and request updates from the other (pull). The push/pull model keeps both servers in sync without needing manual intervention.

After adding the partner, you can adjust the timing of push and pull operations by clicking the “Configuration” button associated with each. The default intervals - typically a few minutes - are suitable for most environments. If you expect rapid changes in host availability, you can shorten the intervals to reduce the window in which a name lookup might fail. Conversely, if you want to conserve bandwidth, you can lengthen the intervals.

Once you have entered the partner’s address and confirmed the timing settings, click “OK” to close the dialog. The new relationship appears in the list of replication partners. You can verify that the partner is online by checking its status column; it should indicate “Online” if the server can reach its counterpart.

Repeat the same process on the second network’s WINS server. Open its WINS Manager, navigate to the Replication Partners menu, add the first server’s IP address, and confirm the push/pull configuration. It is important that both sides have each other listed; otherwise, replication will be one‑way and the network will still experience name resolution inconsistencies.

With both sides configured, you can initiate an immediate replication by selecting the “Replicate Now” button in the dialog. This forces the servers to exchange all current name records right away, ensuring that both have a consistent view of the network hosts. You should see a progress indicator; when it completes, a log entry will confirm that the replication succeeded.

After the initial sync, the servers will continue to replicate on the schedule you defined. It is a good practice to monitor the replication logs for any errors. Windows Event Viewer will report any communication failures or conflicts. If an error appears, double‑check that firewalls on both sides allow traffic on the WINS port (UDP 42) and that the IP addresses have not changed.

Once WINS replication is stable, the clients on both networks will automatically receive accurate name resolution data regardless of which DHCP server hands them an IP address. This eliminates the login failures and name lookup problems that arise when a client is given the wrong domain controller reference. The two LANs now operate as a single logical unit, with DHCP, WINS, and security policies cooperating seamlessly.