One of the latest problems we've run into in our quest to become a truly enterprise-class Linux company is the face that we have a lot of remote workers. Folks who hack from the comforts of their homes and offices around the planet, from places strange and wondrous all call themselves monkeys. This, of course, means that they need access to resources which live on our network.
Easier said than done.
However, as it turned out, all was not well. See, many of our remote hackers live on dynamic IP addresses. Most use some form of NAT on their home networks. The client available for our Nortel Contivity extranet switches is called NetLock, and it's now made by a company called Apani. On the surface, it's just what the doc ordered - a cross-platform piece of software (Windows, Mac OS X, Linux) which allows the user to tunnel into the corporate net.
Problem: This piece of software, despite being distributed teasingly as an SRPM, is in fact a big chunk of binary nastiness hidden inside some wrapper code to talk to the kernel. But it has to be compiled into a kernel module (two, actually) in order to function. And therein lies the rub. It only works with an extremely short list of Linux distros, and then only if you are using bog-standard kernels (it doesn't even like RedHat errata kernels, the silly thing).
Given that our remote workers are developers and testers, they end up running all manner of weird distros and kernels. And some not so weird, but which just didn't work anyway. No go.
After unsuccessfully perusing the list of options amongst the commercial VPN client market (zero) we turned, naturally, to the Open Source software world. OpenVPN, which uses SSL encryption, was a possibility; so was FreeS/WAN. OpenVPN was non-responsive, and while FreeS/WAN could be enticed to work in most cases, it suffered from several problems: one, it was management-intensive (since it couldn't auth using the Corp's native auth solution and hence required X.509 cert generation, distribution, installation and tracking) and two, it simply wouldn't operate from behind a NAT gateway.
bzzzzzzzzt. Thank you for playing. Would you like a nice copy of our OFFICE GAME?
Ah, I hear people shouting, what about Super FreeSWAN? Huh? Hunh?
Well, yes. Except that to work in NAT traversal, it, too, requires a specific kernal patch and recompile. Bzzzzzzzzt.
So there we have it. At present, we're looking at just buying hardware endpoints (little SOHO routers with Contivity logic built in), but those present their own problems. Namely, I can't let people directly in to the network from those, because any time someone opens an 802.11 net in their house behind one of these things, their neighbors can happily surf into my network. Nopenopenopenope.
At the moment, we're looking at setting up a separate DMZ for the VPn endpoint on the corporate end, and then installing a bridge box which users can SSH tunnel through to get to the resources they need - a compromise between access (better than the 'nothing' they have now) and security (that box is still vulnerable, but only to the smaller subset of people who compromise a remote network with one of these endpoints installed).
I'm not sure why this is such an issue, although I have my suspicions. I think that, in point of fact, there aren't that many organizations doing remote linux development that have access requirements for their remote users than go beyond simple SSH tunneling (*cough* NFS sucks*cough*). Or they are willing to accept vulnerabilities or workflow disruptions that we're not. I'm sure many have done this before, but I just can't see how they'd do it without having to make the sort of compromises we are.
Not that the compromises make the task undoable; it's just aggravating. On the other hand, better to find these sorts of problems while dogfooding than when selling the product to the public.Posted by jbz at January 28, 2004 2:53 AM