Re: Ports for Ultra VNC behind a firewall - for remote support

Leythos wrote:

In article <gpvaam$e0a$1@xxxxxxxxxxxxxxxxxxx>, V@xxxxxxxxx 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.
.

Relevant Pages

  • Two routers new attempts
    ... I am still trying to access host PC. ... Linksys BEFVP41 VPN router Main Office Building LAN IP XX.X.X.1 and WAN ip ... Port is open in XP security in both ports 3389 and 1723 for Local Area ... > You would need to change the D-Link address to match your Linksys address range... ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: Port Forwarding PC Anywhere
    ... So I need to set up Port Forwarding so ... directed to the correct host. ... the router via the port forwarding. ... I use different ports for different clients - on my remote computer so ...
    (comp.security.firewalls)
  • Re: How did they get past my NAT?
    ... network), I get no response, because there is no "Default host" set up ... behind my NAT, and no port forwarding for that port - if an explicit ... as I understand?), and not forwarded on the router, so there should be ...
    (comp.security.firewalls)
  • Re: Exiscan+clamav
    ... > # The next three settings create two lists of domains and one list of hosts. ... > # The second setting specifies domains for which your host is an incoming ... > # This router routes addresses that are not in local domains by doing a DNS ...
    (freebsd-questions)
  • Re: Networking Questions
    ... The DNS address is sent as a secondary element, mostly because there's no point for nearly all internet connections without DNS. ... The PC asks for an address by sending a DHCP request out the route to the DSL device which is either a modem or a router. ... No need for DNS until host names get involved and those hosts are on a different network segment. ...
    (comp.sys.ibm.as400.misc)