[mdlug] Need ideas for a "telepresence" box

[Jeff Hanson]

The configuration I suggested makes it their authorization problem, not
yours.  They have to initiate the VPN connection from their side.  The VPN
can connect out on any port but if they are filtering by destination port
number then simply use 80 UDP.  It only affects what services can use the
port at the server end.  You can use 80 TCP but it causes traffic problems
due to TCP error handling when TCP packets are encapsulated in a TCP VPN
connection.


On Fri, Jan 25, 2013 at 4:28 PM, David McMillan <skyefire at skyefire.org>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)
>
> 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>
>>> <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<http://mdlug.org/mailman/listinfo/mdlug>
>>
>
> ______________________________**_________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/**listinfo/mdlug<http://mdlug.org/mailman/listinfo/mdlug>
>