Gary Dale<garyd...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6tc9xmgs....@news.roaima.co.uk