vpnc or openvpn

[seth vidal-3]

On Tue, 2008-03-11 at 12:59 -0400, Robert G. Brown wrote:

> But these are all things distributed by Fedora.  So, is Fedora going to
> kick openvpn out because it is linked to openssl and yet has a GPL, or
> ignore it because if they kicked it out the screams would be heard from
> here to China?  If they're going to ignore it, why can they NOT ignore
> the same thing in vpnc?
>
> Enquiring minds like to know...;-)
>
> REALLY enquiring minds would be looking for a practical non-religious
> solution to this problem, as well -- something like simply shifting
> licenses depending on where a product is, or turning the openssl support
> into a plugin provided under its own license.  But it won't be my own
> enquiring mind that does any of that...
>

Okay maybe I was unclear:

1. openvpn isn't an issue it's GPL license has an exception to allow
linking to openssl. So it can and IS included in fedora legally and
aboveboard

2. Python is not at issue b/c it is PSF not GPL

3. The licensing folks who work on fedora have been over our openSSL
linkages with a comb. Afaik, at this point fedora is clean with regard
to openssl and gpl license issues. However, IANAL and I do not speak for
the licensing folks so do not quote me on this.

4. There are some software which have the gpl exception but HATE having
it and work is going on to make them use nss instead which solves the
issue.

does that clear it up?
-sv




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

[Robert G. Brown]

On Tue, 11 Mar 2008, seth vidal wrote:

> Licensing exception:
>
> in the COPYING file in openvpn:
>
> OpenVPN license:
> ----------------
>
>  OpenVPN is distributed under the GPL license version 2 (see Below).
>
>  Special exception for linking OpenVPN with OpenSSL:
>
>  In addition, as a special exception, OpenVPN Solutions LLC gives
>  permission to link the code of this program with the OpenSSL
>  library (or with modified versions of OpenSSL that use the same
>  license as OpenSSL), and distribute linked combinations including
>  the two.  You must obey the GNU General Public License in all
>  respects for all of the code used other than OpenSSL.  If you modify
>  this file, you may extend this exception to your version of the
>  file, but you are not obligated to do so.  If you do not wish to
>  do so, delete this exception statement from your version.

Ah.  I should have read COPYING -- I just glanced that COPYRIGHT.GPL
file, silly me.  What a mess!  I count at least what, six or seven
licenses for different components!

So is this "difficult" to negotiate, or easy?  One wonders if vpnc
developers have tried.  I'm guessing that the others are the same,
exceptions as well.

    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

[Robert G. Brown]

On Tue, 11 Mar 2008, seth vidal wrote:

>
> On Tue, 2008-03-11 at 12:59 -0400, Robert G. Brown wrote:
>
>> But these are all things distributed by Fedora.  So, is Fedora going to
>> kick openvpn out because it is linked to openssl and yet has a GPL, or
>> ignore it because if they kicked it out the screams would be heard from
>> here to China?  If they're going to ignore it, why can they NOT ignore
>> the same thing in vpnc?
>>
>> Enquiring minds like to know...;-)
>>
>> REALLY enquiring minds would be looking for a practical non-religious
>> solution to this problem, as well -- something like simply shifting
>> licenses depending on where a product is, or turning the openssl support
>> into a plugin provided under its own license.  But it won't be my own
>> enquiring mind that does any of that...
>>
>
> Okay maybe I was unclear:

No, it's just list-lag.  I should just read the whole thread before
replying one item at a time.  Sorry.

> 1. openvpn isn't an issue it's GPL license has an exception to allow
> linking to openssl. So it can and IS included in fedora legally and
> aboveboard
>
> 2. Python is not at issue b/c it is PSF not GPL
>
> 3. The licensing folks who work on fedora have been over our openSSL
> linkages with a comb. Afaik, at this point fedora is clean with regard
> to openssl and gpl license issues. However, IANAL and I do not speak for
> the licensing folks so do not quote me on this.
>
> 4. There are some software which have the gpl exception but HATE having
> it and work is going on to make them use nss instead which solves the
> issue.
>
> does that clear it up?

Absolutely.  And yes, dumping openssl does seem like a very reasonable,
if unfortunately draconian solution.  License proliferation is at least
moderately evil, and of course it is self-inflicted evil in the open
source world where the whole POINT of having open sources is to not have
to screw around with this sort of crap.

I'm not suggesting that it should be taken lightly or anything like
that.  I really did just want to know how it worked, because it seems
relevant to people like e.g. Chris Walter or Sean who've been hacking on
vpnc.  One wonders if the nss_compat_ossl package might not let vpnc
just rebuild and work.  But not enough for one to work on it, at least
if one is me.  Too much to do, short spring break to do it all, and I've
already wasted SO much time on this in the last eighteen hours.

I should never rant.  There is just no point to 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

[Kambiz Aghaiepour-2]

Robert G. Brown wrote:

> Suggestions welcome, although I'm inclined to build/fix vpnclient again
> for F8.  It will probably take less time than any of the alternatives
> unless the patches are REALLY nasty.
>
>     rgb

Try to open tcp port 10000 on your system (and limit it to the VPN peer
of course).  I believe that is the port that the duke vpn concentrator
calls back on.

Kambiz

--
+-  .--.  ----------------------------------+
|  |o_o |      Kambiz Aghaiepour            |
|  |:_/ |    -=-=-=-=-=-=-=-=-=-=-=-=-      |
| //   \ \  "Freedom is not worth having if |
|(|     | ) it does not include the freedom |
/'\_   _/`\ to make mistakes." --M. Gandhi  |
\___)=(___/ --------------------------------+

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

[Sean Dilda-2]

Robert G. Brown wrote:

>   e) I do in fact connect.  By the time I'm entering username and
> password, I'd better be connected to the server and the connection had
> better already be bidirectionally encrypted.
>

Its quite possible for a program to ask for you username/password and
store that in memory *before* ever opening a network connection.  In
fact, I believe that's what vpnc does.  As a test, I changed the gateway
line in my default.conf to an invalid host (but sadly, a hostname that
does resolve due to earthlink's broken dns).  This is what I found:

[agrajag@athyra ~]$ sudo /usr/sbin/vpnc
Enter username for duke-vpnlic.netcom.duke.edu: sdf
Enter password for sdf@...:
/usr/sbin/vpnc: receiving packet: Connection refused


Notice, it attempted the connection *after* asking me for a
username/password.

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

[Robert G. Brown]

On Tue, 11 Mar 2008, Kambiz Aghaiepour wrote:

> Robert G. Brown wrote:
>
>> Suggestions welcome, although I'm inclined to build/fix vpnclient again
>> for F8.  It will probably take less time than any of the alternatives
>> unless the patches are REALLY nasty.
>>
>>     rgb
>
> Try to open tcp port 10000 on your system (and limit it to the VPN peer
> of course).  I believe that is the port that the duke vpn concentrator
> calls back on.

I turned off my local firewall altogether on the f8 laptop.  selinux is
already disabled.  The laptop is bare-naked to the world.  I drilled
explicit port forwarding through my household firewall to my laptop,
even though as noted vpnclient works fine without any such thing on
other non-F8 systems.

Exactly the same symptoms.  In fact, I just burned yet another hour
permuting the location of the certificate, the hash link to the
certificate, the command line arguments, the firewall settings (down to
no firewall at all anywhere on the explicitly given paths).  I have
tried both sean's rpm build and a direct build from the source.

rgb

>
> Kambiz
>
>

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

[Robert G. Brown]

On Tue, 11 Mar 2008, Sean Dilda wrote:

> Robert G. Brown wrote:
>
>>   e) I do in fact connect.  By the time I'm entering username and
>> password, I'd better be connected to the server and the connection had
>> better already be bidirectionally encrypted.
>>
>
> Its quite possible for a program to ask for you username/password and store
> that in memory *before* ever opening a network connection.  In fact, I
> believe that's what vpnc does.  As a test, I changed the gateway line in my
> default.conf to an invalid host (but sadly, a hostname that does resolve due
> to earthlink's broken dns).  This is what I found:
>
> [agrajag@athyra ~]$ sudo /usr/sbin/vpnc
> Enter username for duke-vpnlic.netcom.duke.edu: sdf
> Enter password for sdf@...:
> /usr/sbin/vpnc: receiving packet: Connection refused

That is almost exactly what I see, except that I get no response from
target.  Cranking up tcpdump:

rgb@cain|B:1008#tcpdump -i wlan0 src or dst
duke-vpn-public.netcom.duke.edu
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
14:59:12.567825 IP cain.rgb.private.net.isakmp >
duke-vpn-public.netcom.duke.edu.isakmp: isakmp: phase 1 I agg
14:59:12.899579 IP duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp: phase 1 R agg
14:59:12.920048 IP duke-vpn-public.netcom.duke.edu >
cain.rgb.private.net: udp
14:59:13.567140 IP cain.rgb.private.net.isakmp >
duke-vpn-public.netcom.duke.edu.isakmp: isakmp: phase 1 I agg
14:59:15.567148 IP cain.rgb.private.net.isakmp >
duke-vpn-public.netcom.duke.edu.isakmp: isakmp: phase 1 I agg
14:59:19.567137 IP cain.rgb.private.net.isakmp >
duke-vpn-public.netcom.duke.edu.isakmp: isakmp: phase 1 I agg
14:59:20.978365 IP duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp: phase 1 R agg
14:59:20.999587 IP duke-vpn-public.netcom.duke.edu >
cain.rgb.private.net: udp
14:59:29.071127 IP duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp: phase 1 R agg
14:59:29.091832 IP duke-vpn-public.netcom.duke.edu >
cain.rgb.private.net: udp
14:59:37.004829 IP duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp: phase 1 R agg
14:59:37.025527 IP duke-vpn-public.netcom.duke.edu >
cain.rgb.private.net: udp
14:59:44.970091 IP duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp: phase 2/others R inf[E]
14:59:44.970148 IP cain.rgb.private.net >
duke-vpn-public.netcom.duke.edu: ICMP cain.rgb.private.net udp port
isakmp unreachable, length 128

It looks like the isakmp packets are coming back from the vpn, but
possibly broken or in some form that vpnc is unhappy with -- alas it has
nothing like a verbose mode that I can see.  I'm down to the point where
I have to suspect that e.g. Intrex has a MoM attack running that is
mucking with the packets in transit, or (given that they are UDP) that
some sort of corruption is occurring.  But if so, it is strange that it
hits only the one laptop and not the other, both on wireless.  Maybe it
is the wireless card -- intel on one and broadcom on the other.  Who
knows.

At this point, my laptop has no firewall at all running, and my
household gateway even without all of the port forwarding works with
vpnclient with all the other older systems in the house.  I am quite
sure of this.  I have turned off the firewall both with
system-config-firewall and by running /etc/init.d/iptables stop.  I've
verified with traceroute and tcpdump that I can hit my laptop on isakmp
from ganesh in the physics department:

15:20:18.871923 IP ganesh.phy.duke.edu.32853 > cain.rgb.private.net.isakmp: isakmp:

(from tcpdump on my laptop, indicating that packets to this port are
indeed getting through all intervening barriers).

I'm about done.  This has eaten yet another hour or two.  If anybody can
make sense of the above, please let me know.  Otherwise I have to get
some work done.

   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

[Robert G. Brown]

I hate to reply to myself, but for grins I cranked up tcpdump:

15:40:59.433079 IP (tos 0x0, ttl 121, id 37928, offset 0, flags [+],
proto UDP (17), length 1500) duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp 1.0 msgid : phase 1 R agg: [|sa]
(len mismatch: isakmp 2457/ip 1472)
15:40:59.436387 IP (tos 0x0, ttl 121, id 37928, offset 1480, flags
[none], proto UDP (17), length 1005) duke-vpn-public.netcom.duke.edu >
cain.rgb.private.net: udp
15:41:07.558500 IP (tos 0x0, ttl 121, id 47707, offset 0, flags [+],
proto UDP (17), length 1500) duke-vpn-public.netcom.duke.edu.isakmp >
cain.rgb.private.net.isakmp: isakmp 1.0 msgid : phase 1 R agg: [|sa]
(len mismatch: isakmp 2457/ip 1472)

and the packets are indeed coming in mangled.  I'm not sure in which
direction, though.  The interface has an MTU of 1500 as usual, 1472 is
standard UDP/IP.  I'm not sure what's going on with the isakmp 2457
thing.

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

[Kevin Miller-12]

[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

[Robert G. Brown]

On Thu, 13 Mar 2008, Kevin Miller wrote:

> Robert,

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

Dear Kevin,

All good, but as I said this is a very old problem -- years old, not
months old -- and one that only has required a small FTE investment to
"fix" all along at least at the level of maintaining a functional,
tested vpnclient for linux.  In fact, volunteers on this list (myself
included) would do -- and have in the past offered to and indeed done on
their own anyway -- the required patching of the existing vpnclient FOR
you, so that all your organization has needed to do is spend a couple of
hours testing it and then dropping a link to a functional one in place
on the OIT website for general use.

However, we REQUIRE at least that much OIT participation, because as I
noted, according to the cisco license in the sources themselves it is
technically illegal for us as end users to redistribute functionally
patched sources (not to mention difficult for us to access current
sources to patch) while as I understand it you guys do have the right to
do so within the organization.  I've now twice patched it myself (for FC
6 and FC 7), twice offered to pass it back to OIT, and twice been
largely ignored.  Chris Walter has duplicated this effort.  I'm guessing
that at least four or five others have as well.  Ultimately, working
versions have been passed around through the grapevine, routing around
the barrier, which is not appropriate for the mission critical service
of providing secured remote connectivity and leaves ME taking the risks
associated with violating a license (however annoying it might be that
Cisco doesn't provide a functional product so that I'm more or less
forced to to connect at all).

I'll offer again:  If you will accept a patched vpnclient for Fedora 8
and put it on the website for general distribution to help bridge the
gap between now and when SSL VPN comes on line, I (perhaps with the help
of others on the list) will take the time to build it and test it and
then hand it over.  All I'd need is a copy of the latest/greatest Cisco
tarballs for i386 and x86_64 if there is one more recent than the 4.8 or
4.6 sources I have now (and if the differences matter).

You guys in OIT don't have to work all alone on this, in other words.  I
>>do<< understand that you're busy and that you have many priorities
(and absolutely, fixing some of the semi-broken WAPs around campus is a
very good one to have).  Just realize that you have help -- we can work
together on things to our common benefit.

I'll even apologize for the rant, although to the extent that it has
attracted your attention to the ongoing problem it may have still been a
good thing.  As I said before, I don't particularly like having to
publically complain about things like this to get a constructive
response, but somethings there is little alternative.

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

Excellent.  I'm glad the SSL VPN will indeed be a scalable tunnelling
architecture and hopefully easy for novice-level users to operate from
userspace on the LMW platform base as you describe.  From discussions on
this list I'd have to say that there has been something of a
communications problem even to the campus sysadmin base, but perhaps
this particular discussion we're having now is helping to rectify that
which is all to the good.  Any technical description of the service you
wanted to post to this list or the A&SiST list -- what it's running on,
how it works, what the clients are and where they come from, its overall
cost, an estimate of when it would start to be available -- would
doubtless be appreciated by me and I'm sure many others.

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

Again, an excellent, rational plan.  Sign me up.

    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

[Kambiz Aghaiepour-2]

Dr. Brown,

Sorry for resurrecting this thread so far after the fact.  I didn't have
the means at the time we were (re)discussing the issue with connecting
to Duke's Cisco VPN Concentrator to try to find a solution to this
issue.  I may have found a solution to the problem you were having with
vpnc and and CCing the list in the hopes that others will also benefit.

Please attempt to run vpnc using the following flags:

   vpnc --natt-mode force-natt --local-port 501

So far I have not seen a single failure to connect to Duke networks.

I came across this as a possible workaround when looking through the
vpnc-devel mailing list archives.  I ran multiple tests using a Fedora 8
(i386) patched system and I was at best connecting 10-15% of the time
using no arguments to vpnc,  The failure responses I was seeing were:

   no response from target
   response was invalid [1]:  (ISAKMP_N_PAYLOAD_MALFORMED)(16)
   response was invalid [1]:  (ISAKMP_N_INVALID_COOKIE)(4)

I am using a Linksys cable modem router, and they are apparently
notorious for causing problems with IPSec connections (although I have
options in my linksys to allow for IPSec tunneling).  RFC3947 and
RFC3948 describe ESP encapsulation in UDP which is what the foce-natt
option does.  I suspect that at times the IKE and ESP over UDP tend to
use big UDP packets which will get fragmented, and subsequently dropped.
  For some reason when running vpnc without any options, this seems to
be the case and when using the above mentioned options, this doesn't
happen.  I haven't compared tcpdump output yet.

Please let me know if this helps.

Kambiz

Robert G. Brown wrote:

> <div class="moz-text-flowed" style="font-family: -moz-fixed">On Tue, 11
> Mar 2008, Kambiz Aghaiepour wrote:
>
>> Robert G. Brown wrote:
>>
>>> Suggestions welcome, although I'm inclined to build/fix vpnclient again
>>> for F8.  It will probably take less time than any of the alternatives
>>> unless the patches are REALLY nasty.
>>>
>>>     rgb
>>
>> Try to open tcp port 10000 on your system (and limit it to the VPN peer
>> of course).  I believe that is the port that the duke vpn concentrator
>> calls back on.
>
> I turned off my local firewall altogether on the f8 laptop.  selinux is
> already disabled.  The laptop is bare-naked to the world.  I drilled
> explicit port forwarding through my household firewall to my laptop,
> even though as noted vpnclient works fine without any such thing on
> other non-F8 systems.
>
> Exactly the same symptoms.  In fact, I just burned yet another hour
> permuting the location of the certificate, the hash link to the
> certificate, the command line arguments, the firewall settings (down to
> no firewall at all anywhere on the explicitly given paths).  I have
> tried both sean's rpm build and a direct build from the source.
>
> rgb
>
>>
>> Kambiz
>>
>>
>

--
+-  .--.  ------------------------------------+
|  |o_o |          Kambiz Aghaiepour          |
|  |:_/ | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
| //   \ \  "We can't solve problems by using |
|(|     | ) the same kind of thinking we used |
/'\_   _/`\  when we created them." -Einstein |
\___)=(___/ ----------------------------------+

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

[Kambiz Aghaiepour-2]

I have a modified version of "vpnc" available for Fedora-8 that should
work with Duke's Cisco VPN concentrator.  You may find the "duke-vpnc"
RPM package in either:

  http://install.linux.duke.edu/pub/linux/add-on/duke/fedora-8/i386/

or

  http://install.linux.duke.edu/pub/linux/add-on/duke/fedora-8/x86_64/

Note that the above repos are only accessible if you are connecting from
a system on the Duke networks.

There are small difference between this package, and "vpnc" (found in
the main distribution).

1) I've renamed it to "duke-vpnc" to avoid clashing with the "vpnc"
package, or having the package "upgraded" during nightly yum cron.

2) The rootcert for Duke's Cisco VPN concentrator is included (for phase 1).

3) the configuration is setup to point your system to Duke's IPSec
gateway and includes the required shared secret.

4) the default NATT mode is force-natt and the default local port is set
to 501.

Once you install the "duke-vpnc" rpm,  all you should need to run as
root on your system is "duke-vpnc"  and you will be prompted for your
NetID and passwd, after which you will be on out VPN.

The scripts that setup your routing have also been modified so as to
only route Duke networks over your VPN connection.

To disconnect, simply run "duke-vpnc-disconnect"

Regards,
Kambiz

--
+-  .--.  ------------------------------------+
|  |o_o |          Kambiz Aghaiepour          |
|  |:_/ | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
| //   \ \  "We can't solve problems by using |
|(|     | ) the same kind of thinking we used |
/'\_   _/`\  when we created them." -Einstein |
\___)=(___/ ----------------------------------+

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