Home AMX User Forum AMX General Discussion

Hardware VPN Client for use in places that don't know how to do VPN

Okay, so I have yet another client whose networking people cannot figure out how to set up VPN access. So, they did the "Laptop Onsite with Team Viewer" with no appropriate software installed. And they're confused and angry that I needed to spend the first 4 hours getting the Team View laptop setup and ready to work on an AMX system...

My thought is there used to be a Linksys type box that looked like the old WR57 routers that was actually a VPN server/link. The idea was you put the thing on the network behind the firewall. It would look outward to a cloud-based VPN relay. You would then VPN into the link and viola! You were VPN-ed into their network. Granted it was a bit slow, but it was still better than fighting the Team View interface latency and having to spend a crazy amount of time configuring the client's laptop.

I can't seem to find this thing anymore. I can, however, set up a VPN server on my office network. Does anyone know of a) such a box as I described or b) a stand alone box that can DHCP onto the client's network and then become a VPN client to my office network's VPN server?

I'm trying to find something that is super simple for the client (pretty much power up, plug-n-play. no setup on their part.) I can pre config it and ship it prior to commissioning.

Thoughts anyone?
e

Comments

  • John NagyJohn Nagy Posts: 1,734
    Look into JANUS by the GREENLIGHT folks (our forum buddy Chad Coles used to be with the Greenlight group til recently).
    www.greenlightcontrol.com ... While GREENLIGHT compiles into AMX and other system code to allow status reporting, JANUS is a site-box (I think the plan is raspberry pi) that acts as a secure conduit into the local network from outside, for any ports.

    We're considering building GREENLIGHT into our code as a standard. Then up to the customer if they want to pay the monthly to use it. There's a non-zero chance we can build JANUS into the NetLinx too.
  • ericmedleyericmedley Posts: 4,177
    John Nagy wrote: »
    Look into JANUS by the GREENLIGHT folks (our forum buddy Chad Coles used to be with the Greenlight group til recently).
    www.greenlightcontrol.com ... While GREENLIGHT compiles into AMX and other system code to allow status reporting, JANUS is a site-box (I think the plan is raspberry pi) that acts as a secure conduit into the local network from outside, for any ports.

    We're considering building GREENLIGHT into our code as a standard. Then up to the customer if they want to pay the monthly to use it. There's a non-zero chance we can build JANUS into the NetLinx too.

    Thanks for the reply John. But, I don't think this is what I need. I need VPN access from my office to the client network during commissioning of a system. Once, I'm done with the commissioning, I'm usually out of the picture. I used to work for a company that did a similar thing (CCS) back then there was us and Ihiji.
    But, thanks again.
    e
  • javery1javery1 Posts: 21
    There was recently a discussion on this on the Crestron Programmers Yahoo group. The most popular option seemed to be setting up a tiny PC like a NUC and leaving it in the rack.

    I wonder if this is something OpenWrt could do, installed on a compatible router
  • nickmnickm Posts: 152
    I've used a LOT of solutions for this exact type of thing. I've discovered there really is no silver bullet that fits all scenarios.

    - For bigger commercial projects: I've set up 1U rack PCs that serve as part of an annual service agreement. Typically this would use TeamViewer or ScreenConnect for remote access as most corporate firewalls will allow for SSL 443 traffic outbound without issues.

    - For residential projects, I've set up secure port forwarding to the devices and DDNS. Obviously this is not great for really big installs with lots of masters, but it works on smaller gigs and requires no additional hardware.

    - I've also gone the route you're speaking of and either set up, or had customer IT set up VPN access to the necessary equipment.


    For OPs case, it sounds like setting up a laptop or NUC-type PC would be ideal to ship to site so the customer can simply connect to LAN and be done with it. If this is a common occurrence, I would suggest a robust laptop (like a Dell Latitude or similar) and a Pelican case with a couple accessories that may be needed. (Serial-to-USB, extra USB-Ethernet adapter, etc.)
  • ericmedleyericmedley Posts: 4,177
    In most cases, a lot has to do with the size of the IT firm hiring me, the level of their IP chops and the size of the commercial client they are working for. In most cases, I'm working with the high-up-the-food-chain of all these categories. But, I still get that occasional client who doesn't have the staff on hand who can ask the right questions of the client to get proper remote access.

    It's hard to explain that while it is relatively low-tech to just set up a laptop on site with some kind of remote KVM solution like Join.me or LogMeIn or Team Viewer of whatnot, the issue is it is bandwidth intensive to basically send all that video delta info plus mouse and keyboard throught the guest user WiFi (which is usually heavily bandwidth limited)

    In companies where they have more than one IT person on staff, VPN is almost never an issue; even in my high-security Govt/Military or Financial organizations. They get all the internet security issues and know how to set up VPNs. It's the smaller companies who hired a knows-it-some kind of IT person who barely understands how to set up a router that i run into this problem. I offer to help them configure it. But, that obviously, gets into the whole area of security and that ploy almost never gets me anywhere. On a few occasions I set up my own router to ship and use during commissioning which then get's replaced after everything has been tested and checked off. The last step of that commission is to swap over the network to the client and make sure it all still works.

    Oh well... it is what it is... I knew the answer to the question but hoped for something that didn't involve a PC onsite with remote access. Thanks for the suggestions folks.
    E
  • nickmnickm Posts: 152
    <soapbox>

    This is where we, as programmers, need to start leaning hard on AMX and Harman to update the tools for commissioning/deployment/updating AMX systems.

    They've done well with terminal as standard SSH/Telnet, but now we need the ability to transfer a TKN file to the master and command the processor to unpack and load that file remotely. Proprietary file transfer (through Studio or FTCon is insufficient in the age of continuous integration platforms that should be able to automate rollout of code (Jenkins, Travis, etc). I would also love to see the ability for a processor to check in to a hosted server periodically (RMS, ahem) for updated TKN and TP4/5 files and deploy updates themselves. Or push down from a server directly like we can with firmware.

    This stuff shouldn't be as manual as it is, but here we are with outdated tools. I brought these issues up with technical and management folks at InfoComm, but really just got a deer-in-the-headlights response. Let's start making some noise and letting Harman know that the tools we have are not allowing us to efficiently do our jobs for the betterment of their product.

    </soapbox>

    Apologies for high-jacking the thread.
  • ericmedleyericmedley Posts: 4,177
    nickm wrote: »
    <soapbox>

    This is where we, as programmers, need to start leaning hard on AMX and Harman to update the tools for commissioning/deployment/updating AMX systems.

    They've done well with terminal as standard SSH/Telnet, but now we need the ability to transfer a TKN file to the master and command the processor to unpack and load that file remotely. Proprietary file transfer (through Studio or FTCon is insufficient in the age of continuous integration platforms that should be able to automate rollout of code (Jenkins, Travis, etc). I would also love to see the ability for a processor to check in to a hosted server periodically (RMS, ahem) for updated TKN and TP4/5 files and deploy updates themselves. Or push down from a server directly like we can with firmware.

    This stuff shouldn't be as manual as it is, but here we are with outdated tools. I brought these issues up with technical and management folks at InfoComm, but really just got a deer-in-the-headlights response. Let's start making some noise and letting Harman know that the tools we have are not allowing us to efficiently do our jobs for the betterment of their product.

    </soapbox>

    Apologies for high-jacking the thread.


    No apologies necessary.. :)

    I suppose this kind of feature might jeopardize the hold AMX has within the high-security needs areas such as military / national security / high-end financial. A good portion of my clients fall into these categories. In most cases, those networks are "A Jar" in other words, no connection to the outside world internet at all. And they don't take kindly to devices that seek to find their way out.

    AMX guards that slice of the market with a ferocity that sometimes vexes us. Obviously, they cannot discuss it much since the discussion itself can raise a lot of red flags in the community itself. I know in my work where I am strictly commercial, I do run into markets (like Chicago) where I'm repeatedly asked, "You still do AMX?" But, I can assure you in the verticals I mentioned you hear of nothing but AMX. The other players seem to have difficulty getting through the security tests. Not that you don't see CƦestron but it's nowhere as ubiquitous.

    To me this feature would be a good one to have as a 'switch-onable' option kind of like TP Cloud; something that looks out, and if it finds an update will grab and restart if instructed to do so. It could be made secure enough for the lower-end side of the market where bullet-proof jackets are not required.
  • Nick, several of the mass deployment options you are seeking are available today, and there is a trajectory now visible that should point to a trend in which AMX is heading in these areas. As projects and enterprise deployments continue to grow, managing large quantities of devices are posing greater challenges for integrators and end users alike as they seek to commission and manage their hardware. AMX is leading from the front here with tools, but maybe we just are not marketing them as loudly as we should be. Specifically the mass firmware transfer option available today via RMS and the G5 touch panel file update feature released well over a year ago. Today, G5 touch panels can point to a web location for TPD file transfer. Via configuration settings, you can have the panel take and use the new panel file upon reboot if it is different than the existing panel file currently installed on the panel. The upcoming release of NetLinx Studio will allow you to perform mass firmware updates as well - not as easily as RMS, but it is progress from the one-at-a-time approach of the current tool.

    We understand the challenge, and are working to build tools that will help with this. Another example is a need for the ability to centrally manage device password changes across an enterprise. The typical one-at-a-time approach will not work in larger deployments. A recent challenge faced by one end user was their corporate IT 90-day password reset policy. With one employee dedicated to the task, it would take 95 days to change passwords on the hundreds of devices in their installation. 95 days worth of work, but 90 allowed - and then repeat the process indefinitely? We are focused on creating tools to address the challenges faced in these large scale environments. You don't have to have 5000+ touch panels in a job like the Burj Dubai to appreciate these enhancements. Even a small project with two panels will benefit from these tools. Now with the RMS file transfer utility, there are multiple simultaneous file transfers AND reporting to know who started it and if it was successful.

    Having experienced the pain associated with these tasks first hand - I welcome these enhancements, and I know you will too.
  • nickmnickm Posts: 152
    Thanks for your reply, Chris.

    I appreciate the challenges posed (both perceived and not by us as programmers) by these types of requests. I'm anxious to see the improvements in the pipeline.
  • ericmedley wrote: »

    Thanks for the reply John. But, I don't think this is what I need. I need VPN access from my office to the client network during commissioning of a system. Once, I'm done with the commissioning, I'm usually out of the picture. I used to work for a company that did a similar thing (CCS) back then there was us and Ihiji.
    But, thanks again.
    e

    Janus allows you to connect to any device on the network. The connections will time out so you don't have to worry about anything remaining open. You can buy a Raspberry Pi for $40, pay for one month of service ($8), and use it all you want during the initial setup. Charge your client $48 bucks and you are all set. Then just leave the device onsite and unlicensed. If you ever need to make a change to programming or troubleshoot a device simply pay $8 and re-license it. Janus is also available as a standalone option so you no longer have to have Greenlight running. Basically the Janus unit becomes its own system on Greenlight instead of stacking it on top of a Greenlight system. You lose can still monitor IP devices but you can't monitor any status' through an AMX module and you lose the custom actions, although they are working on "apps" for Janus that will control PDUs and such.
Sign In or Register to comment.