How the IP management supports remote work infrastructure
Why a connected VPN can still fail: address overlap, internal DNS, remote access records and the limits of treating an IP address as an identity.
A colleague can browse the web from home but cannot open an internal application. Their password is correct and the VPN says it is connected. The problem may still be an address or a name: the home network and office use overlapping ranges, or the laptop is asking the wrong DNS resolver.
IP address management makes this kind of problem easier to understand. It gives the team a record of corporate networks, remote-access pools, cloud ranges and the services using them. Its value comes from connecting that record to the actual path a colleague takes to reach work.
Map the path from home to the application
A home router usually assigns the laptop's local address. A corporate remote-access service may supply another address or provide application-specific access. The destination may be in an office, a data centre or a cloud network. These are separate systems, often managed by different people.
The employer's IPAM does not automatically administer the home router. Record the parts the organisation controls and the dependencies it can observe. This keeps support staff from treating an incomplete inventory as a complete view of someone's connection.
Resolve overlaps in the context where they matter
Private IPv4 ranges can be reused in independent networks, as RFC 1918 describes. If a home network and a corporate destination both use the same range, a VPN can introduce ambiguity about which destination a route should reach.
Plan corporate and remote-access ranges together. When overlap occurs, investigate the routes actually installed on the client and gateway. Depending on the architecture, the remedy may involve renumbering a corporate segment, a specific translation design or access to an individual application. Treat it as a network design choice rather than asking every employee to rebuild their home network.
Keep names and addresses connected
DNS turns an application name into the address the client will try. DHCP supplies configuration in networks where it is used. IPAM holds the address plan. DDI is the integration of these three functions; it is not another name for dynamic IP addresses.
Test which resolver handles internal names when the remote connection starts and stops. Check IPv4 and IPv6 behaviour where both are available. An application can fail through its name even when a direct connection to the intended address works, so support procedures should inspect both.
An address helps an investigation; it is not a person
A lease or VPN session can connect an address to a device or account for a period of time. Shared connections, translation and reassignment mean an address alone is weak evidence of identity. Correlate time, session and authentication records when investigating a problem, with access limited to the people who need those records.
NIST's zero-trust architecture treats network location as insufficient grounds for implicit trust. IPAM can supply useful context; identity verification, device checks and application access decisions still need their own controls.
Make joining and leaving predictable
For a new colleague, verify that the account and device can reach the intended applications from a representative external network. Check the remote address pool, name resolution and access permissions. Record failures in the system responsible for them instead of assuming a successful address assignment proves the whole setup works.
When a colleague leaves, revoke access through the identity and remote-access systems. Retire corporate assignments where appropriate and preserve the history needed to understand earlier sessions. Removing an IPAM row alone does not revoke a credential.
Build a useful support record
Start with one remote application and document its path, relevant ranges, resolver and responsible teams. Compare connection success, time to diagnose failures and the number of unresolved record mismatches. Include a test of what still works when the management service cannot be reached.
People should not have to understand the whole network to use it. Good coordination gives local teams enough context to solve a problem and allows the organisation to keep its records when tools change. For the wider principle of inspectable, replaceable coordination, read Lu Heng's Note 72. For the basics, continue with what IPAM does.