Ports for Ultra VNC behind a firewall - for remote support

Discussion in 'Computer Security' started by Leythos, Mar 20, 2009.

  1. Leythos

    Leythos Guest

    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

    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?
    Leythos, Mar 20, 2009
    1. Advertisements

  2. Leythos

    VanguardLH Guest

    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).
    VanguardLH, Mar 20, 2009
    1. Advertisements

  3. Leythos

    Leythos Guest

    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.
    Leythos, Mar 20, 2009
  4. Leythos

    s|b Guest

    I saw someone mentioning ShowMyPC:

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

    s|b, Mar 20, 2009
  5. Leythos

    Leythos Guest

    Leythos, Mar 20, 2009
  6. Leythos

    VanguardLH Guest

    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.
    VanguardLH, Mar 20, 2009
  7. Leythos

    Leythos Guest

    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]
    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.
    Leythos, Mar 20, 2009
  8. Leythos

    VanguardLH Guest

    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

    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

    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).
    VanguardLH, Mar 21, 2009
  9. Leythos

    Leythos Guest

    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
    Leythos, Mar 21, 2009
  10. Leythos

    Martin Guest

    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)
    Martin, Mar 23, 2009
  11. Leythos

    Leythos Guest

    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.
    Leythos, Mar 23, 2009
  12. Leythos

    VanguardLH Guest

    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.
    VanguardLH, Mar 23, 2009
  13. Leythos

    Martin Guest

    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.
    Martin, Mar 23, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.