First, start by trying to ping the device. "No Route to Host" can be deceiving, as a port blocked by a firewall (iptables on Linux) on the remote box could be blocking your connection attempt in such a way that it looks like there's no route to host.
From a command line, type
ping 192.168.2.3 (replacing that with the IP address of the box you're trying to connect to). If you get a successful ping response, then the network layer is working, and you can work your way up the stack. The next thing I would do is try telneting to the port on the remote box, and seeing what error, if any, I get there. From a command line, you can type
telnet 192.168.2.3 1234, replacing the IP and port, respectively, with their values for your environment. If the telnet command succeeds, then you've established a valid network connection, and the problem is at the application layer. If the telnet command fails, then my experience suggests the problem is probably with a firewall blocking the traffic.
If you get an error or ping failure there, then you can concentrate at the network layer. Either the device is not routable, or your source host doesn't have the right routes added, or there is a firewall that is blocking the traffic.
This is also where packet sniffer software, such as the tcpdump or tshark/wireshark (both are frequently included on Linux) can be useful, too. Monitoring the actual network packets as you attempt the connection can tell you whether you are sending packets into a blackhole, or if something is responding telling you that there is a network/route problem, and if so, what is responding in that way?