Re: vpnc or openvpn

On Tue, 11 Mar 2008, Brian Johnson wrote:

> I'm not really sure how to respond to this, however, I know I'm tired of
> sitting by while OIT continues to get bashed.
>
> The fact of the matter is, there are several of us in OIT who are free
> software/open source software/Linux advocates and enthusiasts. Some of the
> most vocal voices on this list come from OIT employees. With all due respect
> Dr. Brown, to imply that OIT doesn't know what Linux is is insulting to
> those of us who care about these things as much as you do.

Dear Brian,

OK, rant, round 2.

Look, I'm not at all suggesting that OIT doesn't have good people and
linux/OS enthusiasts.  My complaint is strictly directed at its
leadership and acceptance of responsibility.  I don't THINK I'm bashing
you (or any of the other OS, or at least non-WinXX, people), unless you
are the person who is in charge of diverting FTE effort to fixing the
problem in AT LEAST ONE OF THE WAYS I suggested, in which case I guess I
am bashing you.

This problem is years old, not months old.  Complaints on this list are
years old -- this, as a part of the general linux support issue on
campus, is a chronic problem.  Fedora 6 is the last supported release on
the campus linux repository and contained the last functional
repackagings of the cisco vpnclient for linux, and it was set up by
Seth, who doesn't work on it anymore, and whose energies were being
diverted from working on it when he was still here. There is work being
done in duplicate and triplicate across many A&S departments because it
is no longer being done centrally and in some sort of coordination with
with both the user base and networking.  There is work being done in
duplicate and triplicate in OIT.  People who work with linux boxes at
home just route around it all, but it is extremely wasteful and time
consuming to have to, especially in an individually replicated manner.

> I believe this has been addressed on this list before, but yes, OIT is
> working on an SSL-VPN client solution. We have 2 folks in Network Services
> who have devoted several months to the project and are very close to having
> it finished. Open source? No. But it's OS agnostic and  it shouldn't break
> every time there's a kernel update either.

Does this explain why OIT has refused to actually patch and release a
functional vpnclient per campus-supported distro?  This actually doesn't
"break" per kernel update -- it just need to be packaged up so that you
type something like "make installrepo" in an encapsulating source
directory inside your e.g. fedora build VMs for i386 and x86_64.  It
probably do require a few hours of work porting per distro update (which
is the only time the underlying library APIs and headers are SUPPOSED to
change, at any rate), which is why nobody rushes to implement a distro
update the first day they come out.  Duke always lags a month or two to
give a new Fedora release time to shake out in the hands of early
implementers and let people figure out the needed patching of stuff like
vpnclient (which SHOULD be done by Cisco, of course, anyway, but what
can you do?).

Why when I (and others) have offered to SEND IN a patched vpnclient so
all that has to be done is replace the tarball you've got on your
secured server (much less than SHOULD be done, but at least something)
nothing happens?  Should I go ahead and grab the current tarball from
OIT, go out to the web myself and figure out how to patch it for F8,
wrap it up in a toplevel encapsulating directory with GBT and a suitable
Makefile.am and vpnclient.spec.in, and make it "zero maintenance" for
OIT for at least the one year plus life of the distro?  I would, if
somebody would PROMISE me to take care of it from then on and actually
run the "make installrepo" to build and distributed the updates required
by a relatively rare kernel update, call it ten whole minutes to
maintain every two or three months with a small possibility of needing
some real debugging or additional patching along the way.

So, here's the interesting thing about my "insulting" OIT -- I actually
DO have the highest regard for your abilities, for Sean's, for Rob
Carter's, for many other people who work in OIT (including several that
left because of the very kind of thing I'm ranting about). It is my
belief that if you were all left alone to just make things work that
they would, and probably a lot cheaper and better than they do now.  I'm
perfectly aware that you and many others are perfectly capable of going
to the web, googling around for a bit, finding instructions for patching
the vpnclient sources, doing it, and testing the result.  I'd even
believe that you could just hack your way through the sources and get
them to work without instructions (a daunting enough task).  Patching
vpnclient, testing it, and putting the patched version up in a tarball
and src rpm, labelled by the linux distro it is patched for is a process
that should take a half-day to a day of FTE for one competent person and
which can be largely automated for future maintenance, since it has
taken little more than that for a number of even less skilled people on
the list, and of COURSE there are technically competent people in OIT --
extremely competent.  If my remarks suggested otherwise in the last
rant, permit me to apologize.

So, given that there ARE plenty of people who are perfectly capable of
fixing this for the public good and use of OIT's user base clients in a
matter of hours, why does this not happen?  Why is it not, in fact,
somebody's "job" to ensure that it happens? When I complain on-list
about it not happening -- for probably the eighth or ninth time over the
last six years, in the context of a never-ending thread that inevitably
provokes reply after reply from all the OTHER people who are struggling,
have struggled, will struggle tomorrow -- why do you respond with the
notion that I'm "insulting" you, or OIT, instead of with the substantive
reply of:

   "Oh my gosh!  You mean the linux vpnclient provided by OIT doesn't
   work with Fedora 8?  We'll have a F8 version fixed and in place by the
   end of the day at the latest, and we'll stand by to support anyone who
   has problems with our patch until it shakes down!"

This is, precisely, what people find annoying about OIT.  OIT isn't an
institution, Duke is an institution.  OIT provides services to the
institution, that is, to users like me. As such, it cannot be "insulted"
-- a service request should never be viewed as an insult, even when they
get a bit strident because they are being utterly ignored.  It should be
a viewed as a problem to be solved.

If I reported something like this to the physics sysadmins (and they
were responsible for fixing it), they would perform triage, move it to
the very top of their mission-critical support queue, and within 24
hours -- probably within two or three hours -- it would be fixed.  In a
day or two it would be fixed "permanently" by embedding the fix in a GBT
shell that permitted one to patch the sources and type "make
installrepo" or the like and have the patched binary rpm automagically
appear in the department yum repo.

This isn't intended to insult anyone, it is just pointing out a matter
of fact, one that can be verified a dozen times over by looking over the
logs of our problem list for any given week.  As far as I know, this is
pretty much the rule across all of A&S, not the exception.  A&S
administrators work for, and with, their client user base, they are
permitted to exercise their own judgement and divert their own energies
to solve problems on behalf of those clients as they see fit, and things
get done.  Not by talking about them or via a committee or as an task
assigned by their "boss" -- they see what needs to be done and do it.
Their users ARE their boss, in a sense.

Now let's talk about SSL VPNs.  It seems clear that you aren't talking
about building a quad core or eight core 1U server, racking it up at the
campus network PoP and putting openvpn on it configured to use SSL/TLS
with suitable ports set up to facilitate this, as that's a fully open
source solution that would cost a few thousand in hardware, a few days
of somebody's time, and would then "just work" forever on pretty much
every operating system, especially if it were installed as a parallel
resource to the existing cisco so it mostly ended up handling non-WinXX
traffic.  I'm not CERTAIN that such a server could handle ALL the
traffic as I lack connection statistics on the existing VPN, but given
that its aggregate network traffic is likely to be bottlenecked at
something like 45 Mbps by the internet backbone itself, not to mention
the fact that its many clients are likely to be locally bottlenecked at
1.5 Mbps or less, it seems like a good bet that it would, certainly
worth trying.

Given the probable capacity to handle at least 10 simultaneous
connections (at 1.5 Mbps) per 64 bit CPU core, an 8 core box would
support 80x1.5 = 120 Mbps and hence overprovision the likely sustained
bw limit for incoming traffic, and it can be configured in round robin
on multiple servers or a server with multiple interfaces so it has at
least some scalability beyond this fairly conservative estimate.  But I
could be wrong, and don't have enough experience -- yet -- with its
scalability, although I quote from the openvpn release notes:

   A highly scalable server for handling multiple TCP/UDP clients over
   point-to-point TUN interfaces, all using a single port number. The
   server has been designed for maximum efficiency and scalability, and
   should scale to hundreds or even thousands of clients where the
   hardware and network bandwidth can support it. The code includes a new
   O(N) scheduler based on a randomized treap binary tree algorithm plus
   efficient hash tables for looking up client instances.

(written long before the advent of multicores and when gigabit
interfaces were still relatively expensive instead of coming two at a
time on any server-grade motherboard).

I therefore assume that you're talking about purchasing a commercial
product that provides "SSL VPN", which if I understand it correctly is a
web/java based one-service-at-a-time portal.  That is, it does not
function as an SSL tunnel that permits a remote client to join duke.edu
with NAT and full access to Duke resources "on the same network" (as
does the cisco or openvpn) it only permits you to do the equivalent of
what ssh tunnels do, one service at a time, but with a niftier front end
to permit you to choose services from a limited menu and otherwise leave
you out in the cold.  Is this correct?  So that the "multiplatform"
support requirement is that the clients must support java so they can
automagically retrieve the proprietary java applets in real-time?

If so, this once again points out the lack of, and need of, an RFC or
other open discussion process on campus for major networking issues.  I
will out of politeness NOT rant on this, but it does seem to me that it
would have been wise, once a decision had been reached to provide an
alternative to the Cisco vpn scheme, to include A&SiST and the major
non-Windows sysadmin and netadmins on campus in the design and selection
process to go over the pros and cons of this sort of scheme.  I don't
THINK that this has occurred, as the people I know who might have been
consulted don't seem to know what exactly you're building, but I could
be wrong.

I have no firm opinion on this, understand -- this is a comment on the
process, not a technical critique which of course I cannot provide
without technical and specific details.  Still, from what I can learn of
commercial SSL VPNs on the web, they seem likely to be WORSE than the
Cisco, not really an improvement, except as a way of letting people
access a small set of very specific services from e.g. completely
unknown hosts when they are e.g. visiting overseas.  Some articles I
read (including the one that I just posted in this thread) were rather
critical of the implicit security model of this sort of solution, ssl or
not, as it makes it rather easy to snoop connections being made from
otherwise completely unsecured public machines at e.g. internet kiosks.
I think most linux people would prefer an SSL tunnel, that is, ideally
one that could be managed from the openvpn client integrated in
NetworkManager and one that requires SOME sort of client side
certificate placed on a machine belonging to the individual connecting,
if not outright signed-certificate client authentication as provided by
openvpn.  But that may be what you are buying, I don't know.

Either way, there seems to be no good reason for OIT NOT to make
vpnclient work while waiting for the project to complete.  Also, forgive
me if I'm skeptical that it has gotten anything like "a few months times
two persons" of FTE, especially if you are basically purchasing a
commercial network appliance, plugging it into a rack, and configuring
it with manufacturer-provided software.  My own estimate for building an
openvpn-based appliance from scratch is less than a week FTE, plus of
course the time required to buy the hardware and have it delivered.  It
took me roughly one hour to get a crudely working bidirectional openvpn
connection going last night, although I'm going to have to negotiate a
port through the trinity router to actually make it for for me from
home.

And yes, I do recognize that you could do exactly the same thing, quite
probably in less than a week FTE.

That, in a way, is the point.  If you, and others who work at OIT,
couldn't, that would be a problem too but one of a different sort (one
that we in fact had a decade or two ago).  It's been years since I've
properly ranted BECAUSE OIT has a lot of good people who generally do
their best to make things work.

When it doesn't happen in spite of this, one can only conclude that
OIT's MANAGEMENT doesn't WANT to fix this problem by maintaining the
linux client for the VPN we already have, doesn't consider linux to be
high enough priority to warrant even a single day of FTE effort to fix
vpnclient and package up the solution for ease of installation and
future maintenance, or to assign the task for fixing it and maintaining
it to an actual person and ensuring that they have free time enough to
do it.

    rgb

--
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977

_______________________________________________
Dulug mailing list
Dulug@...
https://lists.dulug.duke.edu/mailman/listinfo/dulug