Periodically I run into client-server communication issues over a network, where the client cannot see the server, whereas other services don't have an issue. Many times, if I have to phone up support or look up a KB article for a product to resolve the communications issue, they tell me to make sure that the client and server are on the same subnet, even if the server and client are both visible to each other on the network.

Why is this the case for some software and not others? Is this specifically a limitation built into network-enabled software that exhibits these symptoms? I personally have not had any issues when writing network-enabled software when it comes to communicating across subnets, as long as the target system is visible from the client workstation, though my experience in networking protocols is limited.

EDIT Here is a specific example I just ran into today. A VM running Kaspersky Security for Virtualization was unable to see the protection server, which was located on a different subnet, but on the same physical network. Their support told me that it is unsupported to run the client on a different subnet than the protection server, and wouldn't assist me further without placing the VM on the same subnet as the protection server.

I'm not asking for why this wouldn't work for Kaspersky, but in general for different software that do carry these networking restrictions. I'm curious to know if subnet restrictions are an implementation decision (whether it be security through obscurity or something else) or if there are some scenarios where cross-subnet traffic just doesn't work well.

  • 1
    Without clear and specific examples, this question is not answerable. – Sven Mar 6 '15 at 17:38
  • The usual concern is the broadcast domain not functioning as expected. See: Auto Discovery. – Daniel Widrick Mar 6 '15 at 17:53
  • For your example - Why ? Because that's the way Kapersky designed it. – user9517 Mar 6 '15 at 18:49

It sounds like you are asking why does discovery fail across subnets?

"Discovery" can be done in different ways so this is a generalization: Envision a client app that looks for all servers running a particular service by trying to open port 12345 on every IP in the subnet. A single homed server knows of it's own subnet so if a service is not found on the local subnet it doesn't know what subnet to search next so it stops, hopefully.

Discovery can also be done via a broadcast instead of a scan. One type, Netbios discovery broadcasts, by design are limited to the local subnet to reduce the impact on the network and prevent broadcast storms that can eventually take down the network.

Discovery of 1 "server" doesn't mean there isn't a 2nd or 3rd instance running on the same or different subnet so both scan and broadcast discovery methods have some built in limitations.

In this case it seems Kaspersky decided not to implement a more robust discovery method, or provide an alternate method to set the server IP. That's design decision, not a TCP/IP "subnet restriction".


| improve this answer | |
  • Thanks, I think this answers my question, I didn't think about the implications excessive scanning or broadcast storms. – Bender the Greatest Mar 10 '15 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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