Ports for Ultra VNC behind a firewall - for remote support

[Leythos]

I have client that sits behind a real firewall, not a cheap nat router,
and the vendor for the app they use build a Ultra VNC connection into
it.

When the local company starts the help service, it shows the 50+ remote
support connections, but, I can't seem to find a way for the remote
support people to connect back into the workstation with UVNC listening.

There is no way to map individual IP:Port to LAN IP:Port as the stations
are all DHCP assigned....

Anyone doing this that might have an idea?

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[VanguardLH]

Leythos wrote:

> I have client that sits behind a real firewall, not a cheap nat router,
> and the vendor for the app they use build a Ultra VNC connection into
> it.
>
> When the local company starts the help service, it shows the 50+ remote
> support connections, but, I can't seem to find a way for the remote
> support people to connect back into the workstation with UVNC listening.
>
> There is no way to map individual IP:Port to LAN IP:Port as the stations
> are all DHCP assigned....
>
> Anyone doing this that might have an idea?

Unless your router allows port forwarding based on MAC address, all it
has is to forward a port to a particular host by its IP address. That
means you need to use static IP addressing on those particular hosts to
which you want to punch a hole through your router. You need to get
past NAT in the router.

Some remote access products get around the problem by using a local
client. You are using a 3rd party service, like GoToMyPC or Mikogo or
LogMeIn. The client actually makes an outbound connect to the service
which the firewall will allow (just like it will allow your outbound web
browser or outbound e-mail client connects).

[Leythos]

In article <gpvaam$e0a$1@news.motzarella.org>, V@nguard.LH says...
> Leythos wrote:
>
> > I have client that sits behind a real firewall, not a cheap nat router,
> > and the vendor for the app they use build a Ultra VNC connection into
> > it.
> >
> > When the local company starts the help service, it shows the 50+ remote
> > support connections, but, I can't seem to find a way for the remote
> > support people to connect back into the workstation with UVNC listening.
> >
> > There is no way to map individual IP:Port to LAN IP:Port as the stations
> > are all DHCP assigned....
> >
> > Anyone doing this that might have an idea?
>
> Unless your router allows port forwarding based on MAC address, all it
> has is to forward a port to a particular host by its IP address. That
> means you need to use static IP addressing on those particular hosts to
> which you want to punch a hole through your router. You need to get
> past NAT in the router.
>
> Some remote access products get around the problem by using a local
> client. You are using a 3rd party service, like GoToMyPC or Mikogo or
> LogMeIn. The client actually makes an outbound connect to the service
> which the firewall will allow (just like it will allow your outbound web
> browser or outbound e-mail client connects).

In this case the UVNC makes a outbound connection to the provider and
gets a list of available support nodes, you double click on one of them
and then wait - I can't see anything blocked in the firewall, so I can't
tell what the problem is.

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[s|b]

On Fri, 20 Mar 2009 00:42:17 -0500, VanguardLH wrote:

> Some remote access products get around the problem by using a local
> client. You are using a 3rd party service, like GoToMyPC or Mikogo or
> LogMeIn. The client actually makes an outbound connect to the service
> which the firewall will allow (just like it will allow your outbound web
> browser or outbound e-mail client connects).

I saw someone mentioning ShowMyPC:
<http://showmypc.com/>

But in the case of UltraVNC this is perhaps of use?

<http://www.uvnc.com/addons/index.html>

--
s|b

[Leythos]

In article <49c39b62_1@news4us.nl>, me@privacy.invalid says...
> On Fri, 20 Mar 2009 00:42:17 -0500, VanguardLH wrote:
>
> > Some remote access products get around the problem by using a local
> > client. You are using a 3rd party service, like GoToMyPC or Mikogo or
> > LogMeIn. The client actually makes an outbound connect to the service
> > which the firewall will allow (just like it will allow your outbound web
> > browser or outbound e-mail client connects).
>
> I saw someone mentioning ShowMyPC:
> <http://showmypc.com/>
>
> But in the case of UltraVNC this is perhaps of use?
>
> <http://www.uvnc.com/addons/index.html>
>
>
Thanks, I will look at the uvnc link and see if that works for me - the
repeater seems to be the way to go.

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[VanguardLH]

Leythos wrote:

> In article <gpvaam$e0a$1@news.motzarella.org>, V@nguard.LH says...
>> Leythos wrote:
>>
>>> I have client that sits behind a real firewall, not a cheap nat router,
>>> and the vendor for the app they use build a Ultra VNC connection into
>>> it.
>>>
>>> When the local company starts the help service, it shows the 50+ remote
>>> support connections, but, I can't seem to find a way for the remote
>>> support people to connect back into the workstation with UVNC listening.
>>>
>>> There is no way to map individual IP:Port to LAN IP:Port as the stations
>>> are all DHCP assigned....
>>>
>>> Anyone doing this that might have an idea?
>>
>> Unless your router allows port forwarding based on MAC address, all it
>> has is to forward a port to a particular host by its IP address. That
>> means you need to use static IP addressing on those particular hosts to
>> which you want to punch a hole through your router. You need to get
>> past NAT in the router.
>>
>> Some remote access products get around the problem by using a local
>> client. You are using a 3rd party service, like GoToMyPC or Mikogo or
>> LogMeIn. The client actually makes an outbound connect to the service
>> which the firewall will allow (just like it will allow your outbound web
>> browser or outbound e-mail client connects).
>
> In this case the UVNC makes a outbound connection to the provider and
> gets a list of available support nodes, you double click on one of them
> and then wait - I can't see anything blocked in the firewall, so I can't
> tell what the problem is.

Wouldn't all of those outbound connects from their UVNC-enabled hosts
appear to have the same IP address (from their router's WAN-side
boundary)? How would this outside service know how to specify a
particular host? It is trying to communicate with the router, not a
host on the other side of it.

I've used DynDNS in the past to let an outsider know what IP address to
connect to my home network (because the outsider, which is me, can use
an IP name instead of having to remember whatever is the currently
assigned dynamic IP address for my router). No-IP is another one of
these services. You run a client on your host that updates their
service to let them know what is your current IP address. There are
some routers that work with DynDNS or TZO so you don't need to run a
client on a host to get this service updated with your current IP
address (for your router). That solves only half the problem (of
finding your remote host) but you still have to punch a hole through the
router to do port forwarding to your particular host that is listening
for a particular protocol - and it appears you have 50 internal hosts
all wanting to listen on the same port for the same protocol. I doubt
you want to configure each host's VNC server to listen on a different
port and have to punch through the router on a range of those ports and
then have to figure out on the other end which port to use to get at the
correct internal host.

Since the IP address of the internal host is not available once past the
NAT function of the router, an outsider can't initiate an unsolicited
request to it and get past the firewall unless a hole has been punched
through the router and firewall to do port forwarding so the outsider
can connect to (and get forwarded) to the host that is listening for the
unsolicited connect requests. This obviously has security
ramifications, especially if the host isn't in a security zone and isn't
hardened from infection. Anyone on the outside could connect to that
host (and hackers do try). They could even attack that host with fast
repeated connect attempts even with no login credentials.

LogMeIn, Mikogo, TeamViewer, and the like operate as a service provider
that is an intermediary between the outsider and internal host. The
outsider connects to this service provider and requests a session with a
host (which can be by an IP name which will identify a particular host
past the router, a hostname used by that host within its network, or by
a ID number used in the handshaking). The outsider then waits. A
client runs on the internal host that not only notifies this service
what is its IP address (which will be the WAN-side IP address of the
router) but also to check for pending session requests. If there is a
pending session request, the service provider connects the client to the
outsider and then steps out of the way (since they obviously don't
really want to handle that volume of traffic). So both outsider and
client are issuing connect requests to this 3rd party service provider.
That means they both circumvent firewall restrictions because each is
making an outbound connection which is typically allowed. These
services often use a common port for the handshaking from client and
outsider to avoid being blocked by a router, like using port 80 since
most routers are configured to permit HTTP traffic (for outbound
requests initiated by their internal hosts).

Unless this service provider you mention is operating as such a service
and somehow modified UVNC or provided a separate but cooperating client
to do the updates and check for pending session requests at that service
provider, you're stuck with having to punch holes through the router and
firewall to do port forwarding - which means each internal host has to
listen on a different port if more than one internal host is allowed to
connect to the outsider.

There might be some other scheme that allows connections between
internal client host and outsider to get past a router and firewall but
these are the 2 that I've used. I used DynDNS to give me an IP name so
I could use it to find my home host. That solved me finding my host
without having to know its IP address (well, the WAN-side IP address of
the router). I then had to configure the router and firewalls in it and
on my home host to allow port forwarding in the router and unsolicited
inbound connects in the firewalls. I obviously used login credentials
to protect unauthorized access to my host but that certainly would not
block DOS attacks directed at it. I had to leave my host listening for
these unsolicited inbound connects. Eventually I even used this DynDNS
and port forwarding setup to let me use RDP to remotely access my home
host. This was a lot of work and remembering everything that was setup.
It also means I had to define a new "host" at DynDNS to use a different
port (on the client side) to punch another hole via port forwarding to
access a different host in my same home intranet. Instead I went with
LogMeIn which has the client initiate the outbound connection and decide
if it wants to accept any pending session requests that an outsider (me)
established with the 3rd party service provider (LogMeIn). TeamViewer
works in a similar client-initiated collaborative connection by letting
the client give the outsider an ID for a session request they just
established (although TeamViewer can be setup with a permanent ID to
allow inbound connects in much the same way as VNC works but without the
hassles of the outsider knowing the IP address [of the client's router]
and using port forwarding through the router and firewalls).

Hard to tell just what this service provider did with their product when
combined with UVNC. You sure this is an enterprise-level product that
is meant to support multiple internal hosts (on the inside of a NAT
router)? The repeater solution for UVNC (to which SB provided a link in
his post) might work. You are using this managed host to eliminate the
need for the 3rd party session service (LogMeIn, Mikogo, TeamViewer,
GoToMyPC). Basically you manage the host to provide the same session
handling of these 3rd party session providers. So it depends whether or
not this company that uses this product that incorporate UVNC really
wants to add the resources to support this interfacing host, especially
since it is outside the router and probably past their firewall (so it
will have to be a hardened and well-managed externally-facing host).
You still run into the problem of letting the outsider know where to
find this host. It is possible this host can get a static IP address
but users still don't like using IP addresses. You might still end up
using DynDNS, No-IP, or another similar service to give an IP name to
this extranet host. The repeater is doable but more work than using
LogMeIn or other similar providers but you do get to control its
security (or screw it up). Since the company didn't think through how
it was going to get remote service support by using a product that uses
UVNC, I'm not sure they'll bother with having to manage an extranet host
that demands even more security than they now have to commit resources
in managing their router and its firewall.

[Leythos]

In article <gq0rhd$bgq$1@news.motzarella.org>, V@nguard.LH says...
> Leythos wrote:
>
> > In article <gpvaam$e0a$1@news.motzarella.org>, V@nguard.LH says...
> >> Leythos wrote:
> >>
> >>> I have client that sits behind a real firewall, not a cheap nat router,
> >>> and the vendor for the app they use build a Ultra VNC connection into
> >>> it.
> >>>
> >>> When the local company starts the help service, it shows the 50+ remote
> >>> support connections, but, I can't seem to find a way for the remote
> >>> support people to connect back into the workstation with UVNC listening.
> >>>
> >>> There is no way to map individual IP:Port to LAN IP:Port as the stations
> >>> are all DHCP assigned....
> >>>
> >>> Anyone doing this that might have an idea?
> >>
> >> Unless your router allows port forwarding based on MAC address, all it
> >> has is to forward a port to a particular host by its IP address. That
> >> means you need to use static IP addressing on those particular hosts to
> >> which you want to punch a hole through your router. You need to get
> >> past NAT in the router.
> >>
> >> Some remote access products get around the problem by using a local
> >> client. You are using a 3rd party service, like GoToMyPC or Mikogo or
> >> LogMeIn. The client actually makes an outbound connect to the service
> >> which the firewall will allow (just like it will allow your outbound web
> >> browser or outbound e-mail client connects).
> >
> > In this case the UVNC makes a outbound connection to the provider and
> > gets a list of available support nodes, you double click on one of them
> > and then wait - I can't see anything blocked in the firewall, so I can't
> > tell what the problem is.
>
> Wouldn't all of those outbound connects from their UVNC-enabled hosts
> appear to have the same IP address (from their router's WAN-side
> boundary)? How would this outside service know how to specify a
> particular host? It is trying to communicate with the router, not a
> host on the other side of it.

This wasn't my solution, it came pre-setup and the software vendor
normally provides a NAT router to protect the server and computers.

So, same issue, all computers have Ultra VNC listener, they connect to
the software providers VNC Server on the inetnet, and then the software
vendor can see/control the local computer.

I was told by them that it only needs outbound port 80 to work, then I
was told that it needs outbound port 5900, then I was told that they
don't know what it needs....

Being a firewall guy myself I would have expected that the workstation
would reach-out and touch the software provider and that a two way
connection, much like surfing or ftp, would be setup, but there is no
connection showing in the firewall monitor.

[snip dns]

[snip nat]

> LogMeIn, Mikogo, TeamViewer, and the like operate as a service provider
> that is an intermediary between the outsider and internal host. The
> outsider connects to this service provider and requests a session with a
> host (which can be by an IP name which will identify a particular host
> past the router, a hostname used by that host within its network, or by
> a ID number used in the handshaking). The outsider then waits. A
> client runs on the internal host that not only notifies this service
> what is its IP address (which will be the WAN-side IP address of the
> router) but also to check for pending session requests. If there is a
> pending session request, the service provider connects the client to the
> outsider and then steps out of the way (since they obviously don't
> really want to handle that volume of traffic). So both outsider and
> client are issuing connect requests to this 3rd party service provider.
> That means they both circumvent firewall restrictions because each is
> making an outbound connection which is typically allowed. These
> services often use a common port for the handshaking from client and
> outsider to avoid being blocked by a router, like using port 80 since
> most routers are configured to permit HTTP traffic (for outbound
> requests initiated by their internal hosts).

That's how the software vendor stated the UltraVNC connection service is
suppose to work, they provide a server WAN connection for all of their
customers, the customers pick a support rep, and they connect, but I
can't see it attempting the connection in the firewall.

[snip rest]

Thanks for the reply, but, I'm already aware of the NAT issues, been
doing this a long time, but I'm not an Ultra VNC person, so I thought
that maybe I was missing something.

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[VanguardLH]

Leythos wrote:

> In article <gq0rhd$bgq$1@news.motzarella.org>, V@nguard.LH says...
>> Leythos wrote:
>>
>>> In article <gpvaam$e0a$1@news.motzarella.org>, V@nguard.LH says...
>>>> Leythos wrote:
>>>>
>>>>> I have client that sits behind a real firewall, not a cheap nat router,
>>>>> and the vendor for the app they use build a Ultra VNC connection into
>>>>> it.
>>>>>
>>>>> When the local company starts the help service, it shows the 50+ remote
>>>>> support connections, but, I can't seem to find a way for the remote
>>>>> support people to connect back into the workstation with UVNC listening.
>>>>>
>>>>> There is no way to map individual IP:Port to LAN IP:Port as the stations
>>>>> are all DHCP assigned....
>>>>>
>>>>> Anyone doing this that might have an idea?
>>>>
>>>> Unless your router allows port forwarding based on MAC address, all it
>>>> has is to forward a port to a particular host by its IP address. That
>>>> means you need to use static IP addressing on those particular hosts to
>>>> which you want to punch a hole through your router. You need to get
>>>> past NAT in the router.
>>>>
>>>> Some remote access products get around the problem by using a local
>>>> client. You are using a 3rd party service, like GoToMyPC or Mikogo or
>>>> LogMeIn. The client actually makes an outbound connect to the service
>>>> which the firewall will allow (just like it will allow your outbound web
>>>> browser or outbound e-mail client connects).
>>>
>>> In this case the UVNC makes a outbound connection to the provider and
>>> gets a list of available support nodes, you double click on one of them
>>> and then wait - I can't see anything blocked in the firewall, so I can't
>>> tell what the problem is.
>>
>> Wouldn't all of those outbound connects from their UVNC-enabled hosts
>> appear to have the same IP address (from their router's WAN-side
>> boundary)? How would this outside service know how to specify a
>> particular host? It is trying to communicate with the router, not a
>> host on the other side of it.
>
> This wasn't my solution, it came pre-setup and the software vendor
> normally provides a NAT router to protect the server and computers.
>
> So, same issue, all computers have Ultra VNC listener, they connect to
> the software providers VNC Server on the inetnet, and then the software
> vendor can see/control the local computer.
>
> I was told by them that it only needs outbound port 80 to work, then I
> was told that it needs outbound port 5900, then I was told that they
> don't know what it needs....
>
> Being a firewall guy myself I would have expected that the workstation
> would reach-out and touch the software provider and that a two way
> connection, much like surfing or ftp, would be setup, but there is no
> connection showing in the firewall monitor.
>
> [snip dns]
>
> [snip nat]
>
>> LogMeIn, Mikogo, TeamViewer, and the like operate as a service provider
>> that is an intermediary between the outsider and internal host. The
>> outsider connects to this service provider and requests a session with a
>> host (which can be by an IP name which will identify a particular host
>> past the router, a hostname used by that host within its network, or by
>> a ID number used in the handshaking). The outsider then waits. A
>> client runs on the internal host that not only notifies this service
>> what is its IP address (which will be the WAN-side IP address of the
>> router) but also to check for pending session requests. If there is a
>> pending session request, the service provider connects the client to the
>> outsider and then steps out of the way (since they obviously don't
>> really want to handle that volume of traffic). So both outsider and
>> client are issuing connect requests to this 3rd party service provider.
>> That means they both circumvent firewall restrictions because each is
>> making an outbound connection which is typically allowed. These
>> services often use a common port for the handshaking from client and
>> outsider to avoid being blocked by a router, like using port 80 since
>> most routers are configured to permit HTTP traffic (for outbound
>> requests initiated by their internal hosts).
>
> That's how the software vendor stated the UltraVNC connection service is
> suppose to work, they provide a server WAN connection for all of their
> customers, the customers pick a support rep, and they connect, but I
> can't see it attempting the connection in the firewall.
>
> [snip rest]
>
> Thanks for the reply, but, I'm already aware of the NAT issues, been
> doing this a long time, but I'm not an Ultra VNC person, so I thought
> that maybe I was missing something.

Okay, I was thinking the connection was initiated from the outside, not
by the internal client host that connected out. The client (that wants
support) uses his VNC Viewer to connect out on port 80 to the service
provider's VNC server that is listening on port 80. Like any server
that handles multiple concurrent connections, the client and server will
have to renegotiate to use a different socket (IP address + port +
protocol), usually to a higher ethereal port number where the remainder
of their traffic continues after the initial session handshaking on port
80. This is needed for a persistent session so the server can continue
accepting connect requests back on its listening port from other
clients.

Since the clients are connecting to the service provider's VNC server
using the VNC Viewer app on their host, at some point they're going to
have to switch from client to server so the other end can control their
host. That's when port 5900 comes in because that's the default
listening port for a VNC server. But it is this switch (where the
client relinquishes control to the other end) that makes me wonder if
there isn't a problem with the IP address. The other end would be
talking to port 5900 but to the WAN-side IP address of your router.
That's why they mention port forwarding to identify to which internal
host the forwarded port at http://www.uvnc.com/onlinehelp/11.html. For
50 internal hosts, there would be 50 port forwards (or a range of them)
to tell the router which host is associated with which router's WAN-side
port so the other end gets to the correct host.

Just WHO initiates the support session? The outsider or the insider?
If the outsider, the repeater setup mentioned by SB is probably how you
will have to go. If the insider initiates the connection, aren't they
using the VNC Viewer app? The VNC Server listens. It's been quite a
while since I used any flavor of VNC but my recollection is that the
user could switch from VNC Viewer mode (client) to VNC Server mode by
allowing the other side to control the insider's host; however, that
means the insider must not only install the VNC Viewer but also the VNC
Server. When I used an VNC variation, it was me as the viewer client
connecting to a VNC server host to remotely control that VNC server
host. I never switched its role to change me from client to server but
I figure if that's how it is being done there then the problem is with
port forwarding through the router (and where the repeater might come
in).

For some 50 VNC Viewer (client) hosts to be connecting to the service
provider's VNC server means it has to listen on different ports or
handshake to a different socket for each client connect. Well, the
handshaking to an ethereal port means you won't know which one (as the
client) you will get. If the service provider's VNC servers listened on
different ports, each client would have to know which port that
particular host was supposed to use.

Is there really a mode switch where the client host (that is using VNC
Viewer) changes to server mode to relinquish control to the other end?

If the service provider hasn't a clue on how to get their VNC setup to
work then maybe the customer should ask this service provider to abandon
that setup and use something workable, like TeamViewer. With this
product and its use of VNC for remote support, wasn't a support contract
included in the sale of this product? If so, regardless of how the
service provider setup VNC, don't they still have to provide support?
Seems like the service product is just throwing up the hands pretending
stupidity and getting away with it because the customer doesn't enforce
the service contract.

VNC was not designed for multiple connects from either its VNC Viewer
app or the VNC Server so workarounds were found, like the repeater.
That the service provider didn't bother to figure out how to establish
that remote support for their customer that the customer is paying for
sounds fishy. Using VNC means this was some vertical market or custom
product. You sure the vendor of this package actually provides support?
It might've been contracted to include the VNC feature in the product
but there really was no support contract for after the purchase (and the
vendor is just doing it for good faith or image reasons as long as not
too much expense is involved).

[Leythos]

In article <gq1k78$249$1@news.motzarella.org>, V@nguard.LH says...
> VNC was not designed for multiple connects from either its VNC Viewer
> app or the VNC Server so workarounds were found, like the repeater.
> That the service provider didn't bother to figure out how to establish
> that remote support for their customer that the customer is paying for
> sounds fishy. Using VNC means this was some vertical market or custom
> product. You sure the vendor of this package actually provides support?
> It might've been contracted to include the VNC feature in the product
> but there really was no support contract for after the purchase (and the
> vendor is just doing it for good faith or image reasons as long as not
> too much expense is involved).
>

I've not seen it done as the provider states either, always needed a
port mapping inbound to get it working, but I've never tried the method
of the LOCAL user requesting REMOTE support and giving LOCAL control to
the REMOTE person without a direct port map.

The vendor states that this is their standard support method, but I
can't see it working though a firewall without additional direct port
mapping.

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[Martin]

Leythos wrote:
> I have client that sits behind a real firewall, not a cheap nat router,
> and the vendor for the app they use build a Ultra VNC connection into
> it.
>
> When the local company starts the help service, it shows the 50+ remote
> support connections, but, I can't seem to find a way for the remote
> support people to connect back into the workstation with UVNC listening.
>
> There is no way to map individual IP:Port to LAN IP:Port as the stations
> are all DHCP assigned....
>
> Anyone doing this that might have an idea?

Maybe you could afford to use TeamViewer. If you're supporting more than
10 people you should be able to. Don't try it on the cheep you never get
respect, if they pay for it they value it.

It'll be a nightmare trying to configure every VNC client to tunnel
through different ports on a firewall, much easier and less stressful to
use a brokered connection though a port that is always open (HTTP or HTTPS)
>

[Leythos]

In article <49c6d611$0$16164$db0fefd9@news.zen.co.uk>, usenet21
@etiqa.co.uk says...
> Leythos wrote:
> > I have client that sits behind a real firewall, not a cheap nat router,
> > and the vendor for the app they use build a Ultra VNC connection into
> > it.
> >
> > When the local company starts the help service, it shows the 50+ remote
> > support connections, but, I can't seem to find a way for the remote
> > support people to connect back into the workstation with UVNC listening.
> >
> > There is no way to map individual IP:Port to LAN IP:Port as the stations
> > are all DHCP assigned....
> >
> > Anyone doing this that might have an idea?
>
> Maybe you could afford to use TeamViewer. If you're supporting more than
> 10 people you should be able to. Don't try it on the cheep you never get
> respect, if they pay for it they value it.
>
> It'll be a nightmare trying to configure every VNC client to tunnel
> through different ports on a firewall, much easier and less stressful to
> use a brokered connection though a port that is always open (HTTP or HTTPS)

Again, this is not my choice - the software vendor told the customer
that their UVNC solution allows them (customer) to start a session,
connect to the Providers list, and then the provider can back into the
customers computers to provide support.

They are unable to tell me what ports/connections need made in the
firewall and unless this was a normal VNC port mapping, I can't see the
working as they have stated.

--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

[VanguardLH]

Leythos wrote:

> In article <49c6d611$0$16164$db0fefd9@news.zen.co.uk>, usenet21
> @etiqa.co.uk says...
>> Leythos wrote:
>>> I have client that sits behind a real firewall, not a cheap nat router,
>>> and the vendor for the app they use build a Ultra VNC connection into
>>> it.
>>>
>>> When the local company starts the help service, it shows the 50+ remote
>>> support connections, but, I can't seem to find a way for the remote
>>> support people to connect back into the workstation with UVNC listening.
>>>
>>> There is no way to map individual IP:Port to LAN IP:Port as the stations
>>> are all DHCP assigned....
>>>
>>> Anyone doing this that might have an idea?
>>
>> Maybe you could afford to use TeamViewer. If you're supporting more than
>> 10 people you should be able to. Don't try it on the cheep you never get
>> respect, if they pay for it they value it.
>>
>> It'll be a nightmare trying to configure every VNC client to tunnel
>> through different ports on a firewall, much easier and less stressful to
>> use a brokered connection though a port that is always open (HTTP or HTTPS)
>
> Again, this is not my choice - the software vendor told the customer
> that their UVNC solution allows them (customer) to start a session,
> connect to the Providers list, and then the provider can back into the
> customers computers to provide support.
>
> They are unable to tell me what ports/connections need made in the
> firewall and unless this was a normal VNC port mapping, I can't see the
> working as they have stated.

But including remote access support (using VNC) doesn't really preclude
the customer from implementing a different remote access scheme. The
software vendor doesn't even have to install any software (there is a
standalone executable for TeamViewer that doesn't require installation).
If the customer isn't *getting* support by the means the software vendor
provided and support *is* included in the contract then the customer is
still due the support from the vendor. Someone (the customer) isn't
pushing very hard to get the support they paid for.

[Martin]

VanguardLH wrote:
> Leythos wrote:
>
>> In article <49c6d611$0$16164$db0fefd9@news.zen.co.uk>, usenet21
>> @etiqa.co.uk says...
>>> Leythos wrote:
>>>> I have client that sits behind a real firewall, not a cheap nat router,
>>>> and the vendor for the app they use build a Ultra VNC connection into
>>>> it.
>>>>
>>>> When the local company starts the help service, it shows the 50+ remote
>>>> support connections, but, I can't seem to find a way for the remote
>>>> support people to connect back into the workstation with UVNC listening.
>>>>
>>>> There is no way to map individual IP:Port to LAN IP:Port as the stations
>>>> are all DHCP assigned....
>>>>
>>>> Anyone doing this that might have an idea?
>>> Maybe you could afford to use TeamViewer. If you're supporting more than
>>> 10 people you should be able to. Don't try it on the cheep you never get
>>> respect, if they pay for it they value it.
>>>
>>> It'll be a nightmare trying to configure every VNC client to tunnel
>>> through different ports on a firewall, much easier and less stressful to
>>> use a brokered connection though a port that is always open (HTTP or HTTPS)
>> Again, this is not my choice - the software vendor told the customer
>> that their UVNC solution allows them (customer) to start a session,
>> connect to the Providers list, and then the provider can back into the
>> customers computers to provide support.
>>
>> They are unable to tell me what ports/connections need made in the
>> firewall and unless this was a normal VNC port mapping, I can't see the
>> working as they have stated.
>
> But including remote access support (using VNC) doesn't really preclude
> the customer from implementing a different remote access scheme. The
> software vendor doesn't even have to install any software (there is a
> standalone executable for TeamViewer that doesn't require installation).
> If the customer isn't *getting* support by the means the software vendor
> provided and support *is* included in the contract then the customer is
> still due the support from the vendor. Someone (the customer) isn't
> pushing very hard to get the support they paid for.

What he said :) ^

I was too scared to cut anything it sounded so good. To be honest, if
you need to tunnel though firewalls it'll be horrible using individual
connections like VNC going to someone outside your private network, even
more so on DHCP you can't even know the IP address to match up.

Tell the vendor to fork out $1,000 (or whatever) for something that
works properly. Either that or get the vendor added to you network
through a VPN tunnel.

Sorry to the OP, I didn't pick up that you were not the vendor until
later posts.

These things are tough, and as I get older I am more inclined to be
tougher on the vendors. They need to supply support, they will do it my
way. If it costs an extra k or two then so be it. If I can do it, then
they can do it. You're in the driving seat here, you tell them what you
want seeing as you're paying the bills (or your client is).

For this kind of support a brokered connection is needed, and one
that'll tunnel through firewalls with little work on your part. Look at
it from a cost-benefit analysis, if your time costs $200/hour and takes
two days to set up you could have something else in place for 1/2 that -
and the vendor picks up the tab :)

Be assertive! We deserve it.

[Andrew Daves]

You may try establishing a remote connection using a R-HUB remote support server. All you need to do is to forward TCP traffic on ports 80 and 443, and both TCP and UDP on 8889 from your firewall/router to the R-HUB server.