FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-08-2012, 02:13 PM
Gary Dale
 
Default VNC not connecting over SSH tunnel

I'm not having this problem on all machines. 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>


then in another terminal:
xtightvncviewer -encodings "tight" localhost:5902

However, there is one workstation that I get
xtightvncviewer: VNC server closed connection
when I try to connect.

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.
Moreover, I can logout and log back in from the workstation so the VNC
server is running as a service


It's not a machine "suspend mode" thing either. I can't connect even
when the computer is being used.


The remote workstations are running Windows 7.

Any ideas?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FF99570.9000209@rogers.com">http://lists.debian.org/4FF99570.9000209@rogers.com
 
Old 07-09-2012, 12:21 PM
Chris Davies
 
Default 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.

There's your answer in the ssh channel message: there is no route to
there from here.


> 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 routing for the target workstation is different between the two
systems (router and laptop). The fault - if that's what it is - will be
either on the router or on the workstation, and it will either be a fault
of omission (you've lost a route in your routing table) or superimposition
(you've added an incorrect route to the routing table).

Chris


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: iuuqc9xsuo.ln2@news.roaima.co.uk">http://lists.debian.org/iuuqc9xsuo.ln2@news.roaima.co.uk
 
Old 07-09-2012, 03:05 PM
Gary Dale
 
Default VNC not connecting over SSH tunnel

On 09/07/12 08:21 AM, Chris Davies wrote:

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.

There's your answer in the ssh channel message: there is no route to
there from here.



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 routing for the target workstation is different between the two
systems (router and laptop). The fault - if that's what it is - will be
either on the router or on the workstation, and it will either be a fault
of omission (you've lost a route in your routing table) or superimposition
(you've added an incorrect route to the routing table).

Chris
Thanks Chris, but I don't quite follow your direction. 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?


I don't see how the router would enter into it. It just passes the ssh
tunnel to the ssh server, although it does also hand out the dhcp
addresses for the local network. There are no rules on the router
regarding the one workstation.


The other piece of network gear is a 16-port D-Link switch which I
haven't done anything to. I just plugged it in.


So I'm back where I started - why isn't the ssh server seeing the one
particular workstation?




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FFAF342.4070008@rogers.com">http://lists.debian.org/4FFAF342.4070008@rogers.com
 
Old 07-10-2012, 08:41 AM
Chris Davies
 
Default 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.

Chris


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4e6tc9xmgs.ln2@news.roaima.co.uk">http://lists.debian.org/4e6tc9xmgs.ln2@news.roaima.co.uk
 
Old 07-10-2012, 12:01 PM
Joseph Loo
 
Default VNC not connecting over SSH tunnel

On 07/10/2012 01:41 AM, Chris Davies
wrote:



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




While you are at it, why don't you list
the ip addresses and the net mask for each item. ifconfig will
tell you what each machine has.



--
Joseph Loo
jloo@acm.org
 
Old 07-10-2012, 01:36 PM
Gary Dale
 
Default VNC not connecting over SSH tunnel

On 10/07/12 04:41 AM, Chris Davies wrote:

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
Thanks again Chris. If I understand your model correctly, the
"remote_router" is the ssh server and not the actual router that merely
forwards port 22 to the ssh server. To put some numbers to the issue, as
Joseph Loo requested:

homepc is 192.168.1.12
workpc (my laptop) is unknown - I'd have to revisit the office which not
a short trip. It would be in the 192.168.1.x range.

remote_router is 192.168.1.18
remote_workstation is 192.168.1.20

The office router (192.168.1.1) confirms the assignments (I connect to
another remote workstation then log into the office router) as did
opening a command prompt and running ipconfig on the remote_workstation
the last time I was there.


I set up Windows 7 on 6 of the remote workstations and am not aware of
doing anything differently on the non-accessible one.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FFC2FE9.1010607@rogers.com">http://lists.debian.org/4FFC2FE9.1010607@rogers.com
 
Old 07-10-2012, 05:10 PM
Chris Davies
 
Default VNC not connecting over SSH tunnel

Gary Dale <garydale@rogers.com> wrote:
> Thanks again Chris. If I understand your model correctly, the
> "remote_router" is the ssh server and not the actual router that merely
> forwards port 22 to the ssh server.

Yes. It's only now clear to me that the router isn't the ssh server. But
for the purposes of the description consider "remote_router" to be your
internal ssh server.


> remote_router is 192.168.1.18
> remote_workstation is 192.168.1.20

> The office router (192.168.1.1) confirms the assignments (I connect to
> another remote workstation then log into the office router) as did
> opening a command prompt and running ipconfig on the remote_workstation
> the last time I was there.

In that case I'm out of ideas without running something like wireshark
on your "ssh server" to try and see what's going across the wire. Sorry.

Chris


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: o84uc9xsr6.ln2@news.roaima.co.uk">http://lists.debian.org/o84uc9xsr6.ln2@news.roaima.co.uk
 
Old 07-14-2012, 03:30 PM
Gary Dale
 
Default VNC not connecting over SSH tunnel

On 10/07/12 01:10 PM, Chris Davies wrote:

Gary Dale<garydale@rogers.com> wrote:

Thanks again Chris. If I understand your model correctly, the
"remote_router" is the ssh server and not the actual router that merely
forwards port 22 to the ssh server.

Yes. It's only now clear to me that the router isn't the ssh server. But
for the purposes of the description consider "remote_router" to be your
internal ssh server.



remote_router is 192.168.1.18
remote_workstation is 192.168.1.20
The office router (192.168.1.1) confirms the assignments (I connect to
another remote workstation then log into the office router) as did
opening a command prompt and running ipconfig on the remote_workstation
the last time I was there.

In that case I'm out of ideas without running something like wireshark
on your "ssh server" to try and see what's going across the wire. Sorry.

Chris
Went back out to the remote site to check on things. I noticed that the
antivirus on the one computer was set to not respond to pings, which
resolved the question of the server not being able to ping it. Once I
set it to respond to pings, the vnc connection also started working.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 50019085.6050606@rogers.com">http://lists.debian.org/50019085.6050606@rogers.com
 

Thread Tools




All times are GMT. The time now is 09:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org