How to Find Unknown IP Camera Addresses on a Network

Last updated: July 13, 2026

Swapping out cameras with no documentation, no vendor tools, and mixed manufacturers is a common field problem. You do not need the paperwork. The network itself will tell you where every camera lives.

If your actual symptom is the internet dropping the moment these cameras get connected, rather than simply not knowing where they are, jump straight to our guide on why the internet drops when you connect an NVR or DVR instead. This guide assumes you already know which devices you are chasing and just need their addresses.

Step 1: Ask the cameras to announce themselves

Most IP cameras support ONVIF, which uses WS-Discovery on UDP port 3702. A single multicast probe asks every camera on the segment to reply with its address, regardless of brand.

This is the fastest first move because it is brand-agnostic. A probe to multicast address 239.255.255.250 reaches Hikvision, Dahua, Axis, and generic ONVIF cameras alike. They answer with their service endpoints.

Run the built-in nmap script against the local segment:

nmap --script broadcast-wsdd-discover

Cameras typically identify themselves with a device type of NetworkVideoTransmitter in the response. That label alone separates cameras from printers and Windows hosts, which also answer WS-Discovery.

Step 2: Sweep the subnet for everything else

A ping sweep with nmap lists every live host on the subnet. It catches cameras that did not answer the ONVIF probe, including older or non-ONVIF models.

Once you know or can guess the camera subnet, sweep it directly. This returns every responding device, which you then filter down:

nmap -sn 192.168.1.0/24

The problem is that a plain sweep shows every device on the segment, not just cameras. That is where filtering comes in next. That is where filtering comes in.

Step 3: Filter by MAC vendor to isolate the cameras

The first half of every MAC address identifies the manufacturer. Looking up each result’s vendor separates camera hardware from PCs, printers, and other gear in seconds.

An nmap sweep reports the MAC address of each device on the local segment. Paste those into our MAC Address Lookup tool to resolve the vendor for each one.

Camera manufacturers cluster into a recognizable set of vendor names:

• Hikvision and its OEM brands, which cover a large share of the market.
• Dahua, along with rebranded units like Amcrest and Lorex.
• Axis, Bosch, Hanwha, and Uniview for higher-end installs.
• Generic OUIs, which point to budget or white-label cameras built on shared hardware.

For the mechanics of how the OUI-to-vendor mapping works, see our guide on what a MAC address is.

Step 4: Confirm with a port fingerprint

When MAC vendor alone is inconclusive, check open ports. A device with RTSP on 554 plus a web interface and a vendor API port is almost certainly a camera.

Some cameras report a generic or private MAC vendor, which defeats OUI filtering. Port fingerprinting is the tiebreaker. Scan a suspect host for the common camera ports:

Scan a single suspect host for these ports at once:

nmap -p 80,443,554,8000,37777 192.168.1.64

An open 554 combined with a web port is a reliable camera signature. Our port number reference covers what each of these services does in more detail.

When discovery comes up empty

If ONVIF discovery returns nothing, the cameras are almost certainly on a different VLAN or subnet. Multicast WS-Discovery does not cross network boundaries by default.

This is the single most common reason a scan fails, and it is not a sign the cameras are absent. WS-Discovery multicast stays local. It will not cross a VLAN, a router, guest Wi-Fi isolation, or a VPN tunnel.

Two ways forward when this happens:

• Put your laptop on the same subnet as the cameras, physically or by VLAN, then re-run discovery.
• If you can reach the camera subnet through a route, send a unicast nmap sweep against that specific range instead.

An IT contact with details for one site but not the others likely faces exactly this. Each site is its own subnet. Discovery has to run from inside each one.

A note on scope and permission

Only scan networks you are authorized to work on. In a contracted install like a camera swap, that authorization is part of the job. Confirm it before you sweep anything.

Discovery probes and port scans are standard, non-destructive network tools. Used on a client network you were hired to service, they are entirely appropriate. Used elsewhere, they may not be.

If the broader network is misbehaving during your install, our network troubleshooting guide covers the layered diagnostic approach.

Frequently Asked Questions