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.