Slightly OT: VNC Connections

For a couple of years I've sucessfully used UltraVNC for support of
friends and family, so I can tap into their desktops from my PC at home,
and resolve any minor problems with their machines.

Recently I moved from a BT Wholesale connection, to a LLU connection,
still provided by the same ISP. For that to happen they had to change my
static IP address. Not a problem, I simply changed the IP address in
each of the remote U-VNC clients. All can connect to me again, except
for one. I went round there yesterday, and with the help of my wife on
my machine back home tried to resolve the problem. Even with the
software firewalls at both ends switched off, I cannot establish an
connection, with either U-VNC, or bog standard VNC (using my PC as the
server). I cannot even ping my machine from there. I've just tried all
the same from work, and all is fine, so it can't be a problem with my
set up ?

I can't think what is wrong, or suddenly changed, (apart from my IP
address). I've checked that the XP Firewall is off. What else can it be ?

Interestingly the PC that can't connect is on the same ISP as me, but a
BTW connection. Another relation is on an LLU connection with the same
ISP, and they can. Is it possible that traffic is being blocked between
the LLU and BTW sides of the ISP, although I can't see how or why ?

Next weekend I'll take my laptop there, and try to connect with that, to
determine whether the PC or router are at fault.

"Mark Carver" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> For a couple of years I've sucessfully used UltraVNC for support of
> friends and family, so I can tap into their desktops from my PC at home,
> and resolve any minor problems with their machines.
>
> Recently I moved from a BT Wholesale connection, to a LLU connection,
> still provided by the same ISP. For that to happen they had to change my
> static IP address. Not a problem, I simply changed the IP address in each
> of the remote U-VNC clients. All can connect to me again, except for one.
> I went round there yesterday, and with the help of my wife on my machine
> back home tried to resolve the problem. Even with the software firewalls
> at both ends switched off, I cannot establish an connection, with either
> U-VNC, or bog standard VNC (using my PC as the server). I cannot even ping
> my machine from there. I've just tried all the same from work, and all is
> fine, so it can't be a problem with my set up ?
>
> I can't think what is wrong, or suddenly changed, (apart from my IP
> address). I've checked that the XP Firewall is off. What else can it be ?
>
> Interestingly the PC that can't connect is on the same ISP as me, but a
> BTW connection. Another relation is on an LLU connection with the same
> ISP, and they can. Is it possible that traffic is being blocked between
> the LLU and BTW sides of the ISP, although I can't see how or why ?
>
> Next weekend I'll take my laptop there, and try to connect with that, to
> determine whether the PC or router are at fault.

Is the internal IP address of your network different from the internal
address of the remote network? (i.e you can't both have 192.168.0.0 / 24 for
example)

From this remote location, and others, can you ping the external IP address
of your router? Beware that some ISPs block ping traffic as a security
measure.

If you can ping from other sites, but not from the suspect site, try opening
a specific port on the router to allow access to some service. You could
try enabling remote management of the router itself, for example, perhaps on
an unusual port ...

Can you use the routers to set up a VPN between the sites, so that the VNC
traffic (and indeed any other traffic) can be carried over the VPN tunnel
without recourse to any specific configuration of the PC itself?

-- Graham J

On 19/05/2008 15:45, Graham J wrote:

> Is the internal IP address of your network different from the internal
> address of the remote network? (i.e you can't both have 192.168.0.0 / 24 for
> example)

Yes you can. Those addresses will only be internal to each LAN, at
least one end must have a known IP address for the other end to connect
to, in a domsetic setup the router(s) will handle it via NAT and port
forwarding.

On Mon, 19 May 2008 15:45:04 +0100, Graham J wrote:
> Is the internal IP address of your network different from the internal
> address of the remote network? (i.e you can't both have 192.168.0.0 / 24
> for example)

Are you sure about this? The router is usually doing NAT, why would the
LAN range matter?
>
> From this remote location, and others, can you ping the external IP
> address of your router? Beware that some ISPs block ping traffic as a
> security measure.

Some routers and firewalls block ICMP too, stopping 'ping' - but by and
large it will tell you something is responding.

A couple of things cross my mind:
1) IP address correct?
2) Port correct?
3) Nothing else trying to use the same port?
4) Router set to forward VNC port or uPNP doing the job?
5) Software firewall configured OK or REALLY off (some stay active in
memory even after being disabled)
6) Able to ping IP remote IP
7) Is ISP blocking the specific port

If XP Pro on target is the OP able to connect with a simple remote
desktop (enable remote connection in target: control panel>system>[tab]
REMOTE [check] allow computers to remotely connect to this computer. May
need to forward port 3389)

Launch viewer from client [start] [run] open: mstsc [enter]

Probably not useful, but it is all I can come up with off the top of my
head.

Christian wrote:

> A couple of things cross my mind:
> 1) IP address correct?

Yes

> 2) Port correct?

Yes

> 3) Nothing else trying to use the same port?

No

> 4) Router set to forward VNC port or uPNP doing the job?

The router at my end is set to port forward. The UVNC system is such that the
'supportee' has no port forwarding or opening to worry about. (Remember this
is still working OK from six other places)

> 5) Software firewall configured OK or REALLY off (some stay active in
> memory even after being disabled)

Really off

> 6) Able to ping IP remote IP

No. Nor if I install standard VNC viewer on the remote machine, can it connect
to the VNC server running on my PC. That set up uses a different port number.
Again I tested both applications this afternoon from work to home, and they're
fine.

> 7) Is ISP blocking the specific port

Can't be, because as I said in my OP, another person using the same ISP can
connect.

> If XP Pro on target is the OP able to connect with a simple remote
> desktop (enable remote connection in target: control panel>system>[tab]
> REMOTE [check] allow computers to remotely connect to this computer. May
> need to forward port 3389)
>
> Launch viewer from client [start] [run] open: mstsc [enter]
>
> Probably not useful, but it is all I can come up with off the top of my
> head.

I'll give it a go this weekend, thanks Christian.

Further reading on UVNC here:-

http://www.uvnc.com/pchelpware/sc/index.html

--
Mark
Please replace invalid and invalid with gmx and net to reply.

Graham J wrote:

>
> If you can ping from other sites, but not from the suspect site, try opening
> a specific port on the router to allow access to some service. You could
> try enabling remote management of the router itself, for example, perhaps on
> an unusual port ...

I have remote management on my own router, I can't access this from the
problem site either.

> Can you use the routers to set up a VPN between the sites, so that the VNC
> traffic (and indeed any other traffic) can be carried over the VPN tunnel
> without recourse to any specific configuration of the PC itself?

Don't know, that's another thing to try. Thanks Graham.

--
Mark
Please replace invalid and invalid with gmx and net to reply.

Mark Carver <(E-Mail Removed)> wrote:
> Recently I moved from a BT Wholesale connection, to a LLU connection,
> still provided by the same ISP.

> All can connect to me again, except for one [...]

> Interestingly the PC that can't connect is on the same ISP as me,
> but a BTW connection. [...]

> Is it possible that traffic is being blocked between the LLU and BTW
> sides of the ISP, although I can't see how or why ?

It sounds to me very much like your ISP has omitted the route between the
two networks, or else they have declared a route where there is none. If
you're with a competent ISP you'll be able to log a call. If you're with
an ISP that insists on scripting the front line support your chances of
getting this fixed are probably close to zero.

Guessing that you use Windows, it would be interesting to see the output
of TRACERT from the first PC to the second, and also v.v. A sample
command to a host 5.6.7.8 would be "TRACERT 5.6.7.8".

If you want to post these and you have static IP addresses you want
to protect, feel free to mask the last octet at the two end points of
the report.

Chris

Mark Carver wrote:
[snip]
> Interestingly the PC that can't connect is on the same ISP as me, but a
> BTW connection. Another relation is on an LLU connection with the same
> ISP, and they can. Is it possible that traffic is being blocked between
> the LLU and BTW sides of the ISP, although I can't see how or why ?

My first instinct would be to trace to the respective public IP
addresses from each end and see if anything interesting shows up.

> Next weekend I'll take my laptop there, and try to connect with that, to
> determine whether the PC or router are at fault.

If nothing else has changed apart from your connection/address, it seems
unlikely that the problem is under your control.

Alex

Chris Davies wrote:
> Mark Carver <(E-Mail Removed)> wrote:

>
>> Is it possible that traffic is being blocked between the LLU and BTW
>> sides of the ISP, although I can't see how or why ?
>
> It sounds to me very much like your ISP has omitted the route between the
> two networks, or else they have declared a route where there is none. If
> you're with a competent ISP you'll be able to log a call. If you're with
> an ISP that insists on scripting the front line support your chances of
> getting this fixed are probably close to zero.
>
> Guessing that you use Windows, it would be interesting to see the output
> of TRACERT from the first PC to the second, and also v.v. A sample
> command to a host 5.6.7.8 would be "TRACERT 5.6.7.8".
>
> If you want to post these and you have static IP addresses you want
> to protect, feel free to mask the last octet at the two end points of
> the report.

Thanks Chris, I'll give it a try at the weekend, and post the results back
here. My ISP is very competent, their tech support is excellent, so I'll
gather some evidence, and present it to them.

--
Mark
Please replace invalid and invalid with gmx and net to reply.

"Christian" <(E-Mail Removed)> wrote in message
news:4831a9e4$0$26087$(E-Mail Removed)...
> On Mon, 19 May 2008 15:45:04 +0100, Graham J wrote:
>> Is the internal IP address of your network different from the internal
>> address of the remote network? (i.e you can't both have 192.168.0.0 / 24
>> for example)
>
> Are you sure about this? The router is usually doing NAT, why would the
> LAN range matter?

You're right, it doesn't matter.

I thought about it this way:

Assume both sites have a router, remote PC has IP=192.168.0.1 and local PC
has IP=192.168.0.2

Run ping on remote PC.

Packet starts out wth source ip=192.168.0.1 and destination IP as the
external address of OP's router. Because the destination adddress is
outside the local network, ARP arranges to deliver the packet to the default
gateway i.e. the local router.

Packet leaves remote LAN. NAT will occur in the router and the source
address of the packet is modified to show the external IP address of the
remote site. The packet thus appears to originate from that address; it
carries no information about its original source.

Packet traverses internet and arrives at external port of OP's router.

OP's router has port forwarding, so modifies the destination address of the
packet to 192.168.0.2. ARP arranges to deliver the packet to the PC.

The PC replies, to the source address found in the incoming packet, i.e. the
external IP address of the remote site. The packet goes to the local
router, which sends it out to the internet.

Reply packet arrives at the external port of the remote router. NAT checks
the sequence number to verify that the packet is a valid reply to the one it
sent out, if happy, looks up the table of outgoing traffic to find the IP
address of the machine that originated the packet, edits the destination
address accordingly and delivers the packet to the LAN port, from where ARP
delivers it to the correct PC.

So the reason for the OP's problem is either that he has misconfigured
something, or that the traffic is not travelling from one external IP to the
other.

Traceroute should show where the traffic is going. Try it from each site,
ideally simultaneously. The route may well not be the same in both
directions, but it should converge at each end on the relevant router. Try
it to and from other sites; see what commonality exists.

-- Graham J