|
»
»
»
« Return to Thread: vpnc or openvpn
Re: vpnc or openvpn
by Kevin Miller-12
::
Rate this Message:
[Apparently my subscription address was different from my From address,
and as such my responses on this subject have been silently eaten over
time. Sorry about that.]
Robert,
I'm responsible for managing the VPN infrastructure (e.g. Brian and the
rest of the folks working on the VPN work for me); I welcome your
concerns about this or other services at any time. You can email me
directly, or log a request with the help desk (help@...), or
visit a CLAC meeting.
A couple quick factual updates. Currently Duke's Internet and research
network connectivity peaks at around 1.2Gbps inbound. Clearly we're not
talking about VPN tunneling that much traffic, but just to provide a
frame of reference. Our new core backbone is interconnected at 20Gbps,
and shortly we'll be upgrading some research buildings to 10Gbps uplinks
in support of specific applications and efforts.
You are right in that VPN has not been our #1 priority. In the last few
months, we have rolled out the new core network, upgraded the wired
network in several buildings, announced plans to roll out a next
generation 802.11n wireless network, planned the network facilities in
the new enterprise data center, worked towards improved connectivity
between medical and non-medical research facilities, retired our legacy
DNS servers, deployed a virtual firewall service, and evaluated several
vendors for replacement intrusion detection and prevention services.
Alongside all this, though, we have worked methodically to build our
next-generation SSL VPN service. This is truly a tunneled service, not
merely a web proxy. It uses a thin client architecture, and we have been
testing on all 3 major platforms (L, M, W) during the development. A lot
of the time is spent making sure that we have the redundancy and
scalability that is needed of this sort of service. The service will be
virtualized: your VPN may be different from your neighbor's VPN.
The motivation for replacing the VPN service were several, and were
culled from dozens of conversations with IT staff across campus. Among
them, the need for good support across the major platforms, the ability
to virtualize, and a simplified user interface. As well, the current
platform is more than 4 years old and not redundant.
We have shared these plans with CLAC and ITAC before, during, and after
the implementation process (though obviously SSL VPN is still in
progress.) Beyond that, we are more than happy to meet with anyone that
is interested in discussing the services. (If there are other forums
where an opportunity to discuss our services and requirements would be
valued, please let me know.)
While work on the SSL VPN continues, we are preparing to open it to a
wider circle of testers to start gathering feedback on its usability,
functionality, interoperability across platforms, and so forth. Based on
the feedback from this test, we will make changes as necessary to
provide a useful service to the broadest set of uses.
thanks,
-Kevin
Robert G. Brown wrote:
> 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
>
>>
>> Brian
>>
>> On Tue, Mar 11, 2008 at 1:46 AM, Robert G. Brown <rgb@...>
>> wrote:
>>
>>> On Tue, 11 Mar 2008, Jimmy Dorff wrote:
>>>
>>>> Robert G. Brown wrote:
>>>>> Grrrr. Rant over.
>>>>>
>>>>
>>>> FYI: OIT has talked about launching a "SSL VPN" this summer. I don't
>>> know
>>>> any details, but that may help with journal access and such.
>>>
>>> Wow! Such responsiveness! Lessee, summer is only what, three months
>>> away?
>>>
>>> That makes me feel much better. Much. And I'm CERTAIN that they'll
>>> ensure that their new effort has open source clients that are guaranteed
>>> to work under linux.
>>>
>>> Is there something that OIT's many, many employees are doing that is
>>> actually MORE important than fixing VPN access? I'm just curious...
>>>
>>> And you don't have to answer that.
>>>
>>> Let me see how long it takes to set up an openssl vpn with the capacity
>>> to handle pretty much 100% of the off-campus users -- at least to the
>>> limits of its wire. I'll bet it is a time measured in hours.
>>>
>>> rgb
>>>
>>>>
>>>> -Jimmy
>>>>
>>>>
>>>> _______________________________________________
>>>> Dulug mailing list
>>>> Dulug@...
>>>> https://lists.dulug.duke.edu/mailman/listinfo/dulug
>>>>
>>>
>>> --
>>> 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 <http://www.phy.duke.edu/%7Ergb>
>>> Book of Lilith Website:
>>> http://www.phy.duke.edu/~rgb/Lilith/Lilith.php<http://www.phy.duke.edu/%7Ergb/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
>>>
>>
>>
>>
>>
>
_______________________________________________
Dulug mailing list
Dulug@...
https://lists.dulug.duke.edu/mailman/listinfo/dulug
and as such my responses on this subject have been silently eaten over
time. Sorry about that.]
Robert,
I'm responsible for managing the VPN infrastructure (e.g. Brian and the
rest of the folks working on the VPN work for me); I welcome your
concerns about this or other services at any time. You can email me
directly, or log a request with the help desk (help@...), or
visit a CLAC meeting.
A couple quick factual updates. Currently Duke's Internet and research
network connectivity peaks at around 1.2Gbps inbound. Clearly we're not
talking about VPN tunneling that much traffic, but just to provide a
frame of reference. Our new core backbone is interconnected at 20Gbps,
and shortly we'll be upgrading some research buildings to 10Gbps uplinks
in support of specific applications and efforts.
You are right in that VPN has not been our #1 priority. In the last few
months, we have rolled out the new core network, upgraded the wired
network in several buildings, announced plans to roll out a next
generation 802.11n wireless network, planned the network facilities in
the new enterprise data center, worked towards improved connectivity
between medical and non-medical research facilities, retired our legacy
DNS servers, deployed a virtual firewall service, and evaluated several
vendors for replacement intrusion detection and prevention services.
Alongside all this, though, we have worked methodically to build our
next-generation SSL VPN service. This is truly a tunneled service, not
merely a web proxy. It uses a thin client architecture, and we have been
testing on all 3 major platforms (L, M, W) during the development. A lot
of the time is spent making sure that we have the redundancy and
scalability that is needed of this sort of service. The service will be
virtualized: your VPN may be different from your neighbor's VPN.
The motivation for replacing the VPN service were several, and were
culled from dozens of conversations with IT staff across campus. Among
them, the need for good support across the major platforms, the ability
to virtualize, and a simplified user interface. As well, the current
platform is more than 4 years old and not redundant.
We have shared these plans with CLAC and ITAC before, during, and after
the implementation process (though obviously SSL VPN is still in
progress.) Beyond that, we are more than happy to meet with anyone that
is interested in discussing the services. (If there are other forums
where an opportunity to discuss our services and requirements would be
valued, please let me know.)
While work on the SSL VPN continues, we are preparing to open it to a
wider circle of testers to start gathering feedback on its usability,
functionality, interoperability across platforms, and so forth. Based on
the feedback from this test, we will make changes as necessary to
provide a useful service to the broadest set of uses.
thanks,
-Kevin
Robert G. Brown wrote:
> 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
>
>>
>> Brian
>>
>> On Tue, Mar 11, 2008 at 1:46 AM, Robert G. Brown <rgb@...>
>> wrote:
>>
>>> On Tue, 11 Mar 2008, Jimmy Dorff wrote:
>>>
>>>> Robert G. Brown wrote:
>>>>> Grrrr. Rant over.
>>>>>
>>>>
>>>> FYI: OIT has talked about launching a "SSL VPN" this summer. I don't
>>> know
>>>> any details, but that may help with journal access and such.
>>>
>>> Wow! Such responsiveness! Lessee, summer is only what, three months
>>> away?
>>>
>>> That makes me feel much better. Much. And I'm CERTAIN that they'll
>>> ensure that their new effort has open source clients that are guaranteed
>>> to work under linux.
>>>
>>> Is there something that OIT's many, many employees are doing that is
>>> actually MORE important than fixing VPN access? I'm just curious...
>>>
>>> And you don't have to answer that.
>>>
>>> Let me see how long it takes to set up an openssl vpn with the capacity
>>> to handle pretty much 100% of the off-campus users -- at least to the
>>> limits of its wire. I'll bet it is a time measured in hours.
>>>
>>> rgb
>>>
>>>>
>>>> -Jimmy
>>>>
>>>>
>>>> _______________________________________________
>>>> Dulug mailing list
>>>> Dulug@...
>>>> https://lists.dulug.duke.edu/mailman/listinfo/dulug
>>>>
>>>
>>> --
>>> 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 <http://www.phy.duke.edu/%7Ergb>
>>> Book of Lilith Website:
>>> http://www.phy.duke.edu/~rgb/Lilith/Lilith.php<http://www.phy.duke.edu/%7Ergb/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
>>>
>>
>>
>>
>>
>
_______________________________________________
Dulug mailing list
Dulug@...
https://lists.dulug.duke.edu/mailman/listinfo/dulug
« Return to Thread: vpnc or openvpn
| Free embeddable forum powered by Nabble | Forum Help |
