Would it be possible from a central server, communicating with two clients {A, B}, to determine if A and B are physically located on the same local network?

1) Local/Home Networks

I'd say sure. The user's NAT/router would indicate an identical IP address of A and B.

2) Larger networks with multiple gateways

My concern comes in on larger, wireless networks (e.g. an airport). If I have two IPs for A and B who connected to a wireless network through different routers, can I make any assumptions about the airport's network based on the IP addresses of A and B? I could probably get to some top-level information via reverse-IP lookup, but that might not be good enough for a very large network (like a university wireless network). The answer here is probably "no..."

Lastly, what if A and B could provide information TO the central server? This is where my networking knowledge gets hazy. If both A and B have the same gateway and a "similar-enough" public IP, I should be able to assume they are on the same local area network, correct? What are the flaws in this assumption?

4 Answers 4


To add a different perspective to the already provided answers.

When an application wants to do transfers between clients on the same network without proxying through some sort of remote server, the application typically makes use of Broadcasts to allow the clients to "detect each other" on the same network.

This is how Windows NFS works, in fact. Windows machines broadcast to each other over the local network to determine what other machines are on the workgroup, and or what resources are available for sharing.

Dropbox does the same thing. If my phone and my laptop are connected to the same Dropbox account and connected to the same WiFi. What I share on my phone gets synced to my PC with a local LAN communication. (My phone will still upload to DropBox on the Internet, but it would spare my PC from having to download the new file from the Internet, since it is available at a higher speed locally)

To tie it back in to your question. There isn't a way for a remote server to learn whether two clients might be on the same network. BUT, there is absolutely a way for the two clients to discover for themselves whether they are on the same network, and then report their 'finding of each other' back to the remote server.

As Ron said, the Remote server can't assume the two clients are on the same LAN if they share an IP address. Neither should the two clients assume they are on the same LAN just because they share the same Gateway (or even Gateway MAC address, HSRP mac address collisions are not as rare as you think), or each have an address in the same IP Network. Their surefire way of detecting whether they are on the same network is via some sort of discovery mechanism.

  • 1
    Of course, there are exceptions to this, like Private VLANs, which restrict hosts on the same VLAN from contacting each other. The real point is that only the clients may be able to tell the remote server, but it is certainly not foolproof. The remote server itself really has no way to know for sure.
    – Ron Maupin
    Sep 29, 2015 at 18:12
  • @RonMaupin Good call. +1. There are always exceptions ;)
    – Eddie
    Sep 29, 2015 at 18:22
  • This is a great point - client-to-client identification, followed by individual communication with the central server would fit my system nicely. There is a security element to this as well, so I'll need to think about the threat model with the introduction of broadcasting.
    – Jmoney38
    Sep 30, 2015 at 1:45
  • Although, if they are on Private VLANs, then for all intents and purposes, they are on different networks.
    – Eddie
    Oct 27, 2015 at 15:10

short answer is no way to know the local IP address (the private IP) of remote host . except you show the ARP address table or any sort of administrative show on L3 device connected to the remote site it self


There is really no way for a remote server to know if two clients are on the same local network. Even with the same public address, you can't know that they are not across the country from each other since they may belong to a company with multiple sites that uses a central proxy or firewall using NAT.

  • That is a great point - but what if both clients (A and B) could provide their "local" view to the server? A local view might include the gateway. I'm not sure what else might be possible. For my purposes, I'm not overly concerned with VPNs or situations in which a user explicitly redirects their network traffic.
    – Jmoney38
    Sep 28, 2015 at 21:17
  • You would really need some sort of agent on the clients that could give you a local view of the IP address, subnet mask, and gateway, but that still won't completely give you what you are asking. This discussion is getting away from what is allowed on this forum, and getting into a discussion about discovery of network topologies for networks outside your control. That is probably something that the owners of these other networks don't wish to disclose.
    – Ron Maupin
    Sep 28, 2015 at 21:24

There are some tricks that let you know the local IP address of a client that is connecting to the server through a proxy / NAT.

One of them is making the client run a java applet that checks and send the local IP to the server.

Some VPN clients let out the local IP address and also some browsers let it be known to the server when there is a WebRTC request. (This is not a feature, it's a bug so probably it wil be corrected soon).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.