Deep Dive Guide

Networking Field Guide: Hunting a Rogue IP Conflict

A practical, step-by-step networking field guide for troubleshooting rogue IP address conflicts on your LAN. Learn the common causes, quick symptoms to watch for, and exact commands/tools (nmap, arp, Wireshark, etc.) to identify conflicting devices and resolve the issue quickly.

Prove it is a duplicate-address event before chasing switching or DHCP noise.

Start from the affected client and capture exactly what address is conflicting, whether the conflict is continuous or intermittent, and whether the host is using DHCP, a reservation, or static addressing.

Runbook note: Capture evidence before releasing or renewing the address. The original MAC, ARP table, and switch port data are the fastest path to the rogue device.

  • Check whether the client shows a duplicate-address warning, drops off intermittently, or alternates between healthy and broken network access.
  • Record the IP, subnet mask, default gateway, lease state, DNS servers, hostname, and local adapter MAC.
  • Confirm whether the same issue affects one VLAN, one switch stack, one room, or one reservation range.
  • Determine whether the conflicting endpoint is another managed device, a printer, a lab host, a rogue DHCP source, or an old static assignment.

Command path:

  • ipconfig /all
  • arp -a
  • Get-NetIPAddress | Sort-Object InterfaceAlias
  • Get-NetNeighbor -AddressFamily IPv4

GUI path: Windows Settings > Network & Internet > Advanced network settings, or Control Panel > Network Connections > adapter Status > Details.

Use ARP and active probing to find the second device owning the address.

Once the affected address is known, identify the MAC currently answering for it and compare that value against DHCP leases, switch CAM tables, wireless controllers, and asset inventory.

  • Ping the conflicting address from a clean host on the same subnet so the ARP entry is refreshed before reading the MAC.
  • Compare the ARP MAC with the MAC of the affected endpoint to confirm you are truly seeing another responder.
  • If the MAC changes over time, suspect wireless roaming, hypervisor bridges, or a duplicate static configuration rather than a single always-on rogue device.
  • If no ARP entry appears but users still report conflicts, investigate duplicate DHCP assignment timing or stale switch security logs.

Command path:

  • ping <conflicting-ip>
  • arp -a <conflicting-ip>
  • nmap -sn <subnet>/24
  • Get-DhcpServerv4Lease -IPAddress <conflicting-ip>

GUI path: DHCP Manager > IPv4 > Scope > Address Leases, plus switch or wireless-controller MAC lookup tools.

Map the MAC to the actual port, AP, or host platform before making changes.

The conflict is not solved until the team knows where the duplicate endpoint physically or logically lives. That usually means switch MAC tables, access-point client lists, hypervisor port groups, or VPN client inventories.

  • Look up the MAC on the access switch first, then follow uplinks if the table points upstream.
  • If the MAC resolves to an AP or controller, inspect wireless-client history to find the associated device name and user.
  • If the MAC belongs to a virtualization host, check bridged VMs, lab images, and cloned templates for stale static IPs.
  • If the MAC belongs to a printer, camera, or appliance, verify whether it was moved across subnets without readdressing.

Command path:

  • show mac address-table address <mac>
  • show arp | include <conflicting-ip>
  • Get-VMNetworkAdapter -VMName * | Select VMName,MacAddress

GUI path: Switch management UI > MAC address table, wireless controller client view, or hypervisor networking console.

The fix path depends on which authority assigned the duplicate address.

Duplicate IP events usually come from one of three sources: a static device placed inside a DHCP range, overlapping DHCP scopes or rogue DHCP service, or a reservation/static mismatch where operations assumed an address was still free.

  • If the conflicting device is static, move it outside the dynamic range or convert it to a DHCP reservation with documentation.
  • If DHCP issued the same address twice, inspect conflict detection, lease replication, failover health, and any unauthorized DHCP responders.
  • If the address was reserved for one asset and reused elsewhere, correct the inventory and remove stale reservations or retired device assumptions.
  • If the issue followed a VLAN change, confirm the scope, helper address, and subnet mask are aligned with the new network design.

Command path:

  • Get-DhcpServerv4Scope
  • Get-DhcpServerv4Lease -ScopeId <scope-id>
  • Get-DhcpServerv4Reservation -ScopeId <scope-id>
  • ipconfig /release && ipconfig /renew

GUI path: DHCP Manager > Scope Options, Address Leases, Reservations, and Server Properties for failover or conflict-detection review.

Make sure the conflict is actually gone and not just temporarily quiet.

After the rogue device is corrected or readdressed, validate from the original host, a second clean client, and the infrastructure layer so the problem does not reappear after cache refresh or lease renewal.

  • Clear stale ARP entries on affected hosts and verify the correct MAC now owns the address.
  • Renew DHCP on impacted clients if the environment uses dynamic addressing and confirm they receive the expected scope options.
  • Retest application access, gateway reachability, DNS resolution, and any system that was previously flapping.
  • Monitor the switch or controller for the duplicate MAC and address pair over at least one normal business cycle.

Command path:

  • arp -d *
  • ipconfig /flushdns
  • Test-NetConnection <gateway-ip>
  • Resolve-DnsName <internal-hostname>

GUI path: Event Viewer, DHCP logs, and switch monitoring dashboards used to confirm the duplicate condition has stopped recurring.

Turn the incident into cleaner IP ownership and faster future isolation.

The long-term fix is operational discipline: documented reservations, static-address standards, duplicate detection on critical scopes, and known processes for moving printers, appliances, and lab devices between VLANs.

  • Reserve infrastructure and fixed-function addresses outside the dynamic pool or formally assign them as reservations.
  • Maintain switch-port and asset records for non-user endpoints that commonly get moved by facilities or field teams.
  • Review DHCP failover, scope overlap, and unauthorized DHCP protection if the environment has multiple possible address sources.
  • Add the incident details to HelionFall with the IP, MAC, VLAN, and root-cause type so the next recurrence is faster to resolve.

Command path:

  • Get-DhcpServerv4ScopeStatistics
  • Get-DhcpServerInDC
  • Get-NetAdapter | Select Name,MacAddress,Status

GUI path: DHCP Manager, switch inventory, IPAM, and asset-management tooling used to document and prevent recurrence.