Gary Dale<garydale@rogers.com> wrote:
I can connect to every workstation in a remote office using:
ssh -L 5902:<remote workstation's local IP>:5900<remote router's
public IP>
xtightvncviewer -encodings "tight" localhost:5902
However, there is one workstation [...]
The ssh session also shows this message:
channel 3: open failed: connect failed: No route to host
Indeed, I can't even ping it from the remote ssh server.
However, when I went to the office and tried to connect using my laptop,
connected into the local network, I was able to connect normally.
The ssh server is on the local subnet (a 192.168.x.x non-routable
network) as are the workstation I'm trying to connect to and the laptop
(when I plugged it into their network). The local forwarding would be
handled on the subnet so that if it worked for one station, shouldn't
it work for all?
We have four devices to consider:
homepc Your own system, outside the office
workpc Your own system, inside the office
remote_router The end-point for the primary ssh transport
remote_workstation The target machine for the VNC session
Homepc and workpc might be the same, but as they have different IP
addresses I'll name them differently.
At the risk of stating the obvious, I'm going to do it anyway:
* There has to be a route between homepc and remote_workstation for
the ssh transport to succeed. This works
* There has to be a route between workpc and remote_workstation for
the native VNC session to succeed. This works.
* There has to be a route between remote_router and remote_workstation
for the VNC session to succeed. This doesn't work.
The error "No route to host" is often triggered when the source has a
route to the target but the target is not responding to the arp request.
I initially suggested that there is a routing issue between remote_router
and remote_workstation, and this was further evidenced by you not being
able to ping remote_workstation from remote_router. You've then
explained that the network topology is flat and that the remote_router
and remote_workstation are on the same subnet.
I can only suggest at this stage that you go back and re-check the IP
address assigned to the "non-working" remote_workstation.
Chris