[mdlug] Need ideas for a "telepresence" box

[Aaron Kulkis]

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 quite simple:

"You have paid us $X so far.  Upon delivery, we will be paid $Y more.
Now, you are demanding that we provide remote support, but at the same
time, actively obstructing any and all means of providing remote
support.  You have two choice:
"1.  Continue the current policies of obstruction, and when the system
needs a knowledgeable person to work on it immediately, claim breach of
contract, in which case, we will present our case to the court that you
have obstructed all reasonable means of providing the support which you
are paying for, and you get to explain to the big chiefs why your
operation is not working properly DESPITE spending a $(X+Y) on our
equipment, and start sending out CV's for a new job.
"2. Cancel the contract, and then do the same thing again with some
other vendor, spending more money out of your budget with the same
bad results, and again, start sending out CV's for a new job.
"3. You decide WHICH method of access you want us to use, and then
push through the appropriate policy changes to make it happen.

"You're essentially telling us to make a delivery, but refusing to
turn over the package to the truck driver.  If you want this to work,
then put me in touch with people in IT who both know how, and have
the authority to make the right call so that this will work.
"If you're going to be a BAD, non-cooperative customer who demands
what is literally impossible, we won't mind losing your business."



>
> 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