[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: VNC not connecting over SSH tunnel

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.


Reply to: