[mdlug] Need ideas for a "telepresence" box

Aaron Kulkis akulkis00 at gmail.com
Sun Jan 27 13:54:42 EST 2013


David McMillan wrote:
>      Actually, part of the problem is that they have a strong "no VPN" policy.  Not for "guests," anyway -- the network connection they provide for visitors is port-limited to HTTP only -- even HTTPS is blocked, to say nothing off SSH/SFTP.
> Basically, you're allowed basic web browsing, and that's it.  Getting them to open *any* other port in the firewall to the outside world looks to be an uphill battle (both ways, barefoot, in the snow, etc etc).  And trying to "sneak" through
> unguarded ports in their firewall opens us up to lawsuits  or million$ in breach-of-contract penalties.  Which is why I'm searching for an alternative where they "can't stop the signal, Mal."
>      (Another part of the problem is that I can't talk to any actual *techs* in their IT dept -- I keep getting routed to managers who get all glassy-eyed and start reciting their corporate IT mantra whenever I start trying to talk ports, protocols,
> and client/server architectures)
>


It's simple. "You have paid us $X so far.  Without your cooperation, you
will receive a product which will not work until you do cooperate.  The
ball is in your court."

> On 1/25/2013 11:47 AM, Jeff Hanson wrote:
>> I don't know about communications in Europe but if you can connect the
>> system to their LAN then there is a way to ignore their IT department (and
>> security concerns they may have).  Set up an OpenVPN server and certificate
>> authority on your end and pre-configure a system on the client end to
>> connect to it.  You have to generate a certificate for the client which
>> makes it much more secure than just using a password.  Set it to manually
>> connect so they have to initiate the connection.  When they establish the
>> VPN, you can connect back through it using SSH, X2Go, VNC, RDP, etc.  Set
>> you server to use port 443 UDP which their firewall is unlikely to block.
>> If they don't trust your equipment then they can add a hardware firewall
>> (your equipment on the WAN port) that forwards 443 UDP to their gateway.
>> You can still use 443 TCP for hosting a secure web server.  For
>> establishing the connection the client can use the static IP of the server,
>> DNS, or DDNS.
>>
>>
>>
>>
>> On Fri, Jan 25, 2013 at 1:20 PM, David McMillan <skyefire at skyefire.org>wrote:
>>
>>>      My situation is this:  I have a large industrial system that is being
>>> shipped before long to the end customer in Western Europe. The machine has
>>> a number of Human-Machine Interfaces that are essentially Windows PCs with
>>> special GUIs, running on their own fixed-IP LAN.  The customer wants my
>>> employer to be able to do remote support of this machine on 5min notice,
>>> but their IT department is being all kinds of obstructionist.  So I'm
>>> thinking of doing an end run:  divorce this machine from their corporate
>>> network entirely (it doesn't need to be on their main network for
>>> production) and simply add a box (preferably Linux, but that might not be
>>> my call) to the LAN with a cellular modem, DynDNS, VNC, and a few other
>>> software tools that need to run locally (for example, I'll probably need to
>>> be able to run two lightweight WinXP virtual machines in parallel for some
>>> proprietary diagnostic software that, sadly, has no Linux version).
>>>
>>>      Of course, the biz being what it is, I'm not going to have a chance to
>>> test out this rig before it ends up on the other side of the pond.  So I'm
>>> soliciting opinions on whether this is a workable idea, and what I
>>> can/should do to have a bulletproof setup from the start, to avoid any mad
>>> scrambles later in the game.
>>>
>>>      For that matter, does anyone know much about cellular modems and
>>> service in Western Europe?  I keep hearing (mostly from bragging Euroids)
>>> how much better, faster, and cheaper their Internet is than in the US, but
>>> I don't know much about the details.  Particularly, what it takes to get a
>>> good broadband wireless data plan without taking a multi-year contract and
>>> getting into international financing issues.  If they have pay-as-you-go
>>> plans that we could refill remotely at need, that might be the way to go.
>>> ______________________________**_________________
>>> mdlug mailing list
>>> mdlug at mdlug.org
>>> http://mdlug.org/mailman/**listinfo/mdlug<http://mdlug.org/mailman/listinfo/mdlug>
>>>
>> _______________________________________________
>> mdlug mailing list
>> mdlug at mdlug.org
>> http://mdlug.org/mailman/listinfo/mdlug
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug



More information about the mdlug mailing list