vpnc or openvpn

[Michael Ansel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Mon, 10 Mar 2008, Michael Ansel wrote:
>
>> So, in the interest of all Duke-Linux users, is there any University
>> policy preventing us from setting up an openvpn server that uses the
>> Kerberos to authenticate users? Maybe set a bandwidth cap so you don't
>> top your personal 5G upload limit? Or, set one up, and then convince the
>> University to sanction it and remove the upload limit...


Okay, so hard at work trying to figure this one out, but not exactly
sure where to go. I'm trying to eliminate client-side certificates and
only use a local authentication module (currently set to allow any
user/pass, but that can be replaced with pam-krb5). However, something
is failing at the final routing stage (after I'm all connected). I can
ping 10.8.0.1, but nothing else. I'm turning the firewall back on for
now, so you won't be able to connect to my box, but if somebody wants to
work on it tomorrow, I'll be happy to open the VPN port up for you to
check it out.


Thanks, and hope we can get this set up and working soon!

Michael



Server config (server.ovpn): http://pastebin.com/m597d6e5
Server commandline: openvpn --auth-user-pass-verify /bin/true via-file
- --config server.ovpn

Client commandline: openvpn --client --auth-user-pass --dev tap --ca
/home/mra13/ca.crt --remote michael-nas.dorm.duke.edu --comp-lzo
route del default ; route add default 10.8.0.10
10.8.0.10 is the remote end of the PTP link according to the client output.

Server Output:
Tue Mar 11 01:34:01 2008 152.3.66.208:1194 MULTI: bad source address
from client [152.3.66.208], packet dropped
....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBR9YbUXlxmnp6j2qxAQIDgAf7By4Jh2I/jY9+GRVlsyADSju0nRs7kJ+C
liqwaoRaKIbSalQdYukOrngYLnkBuipiKwwhDNfUBkpvxehAk/4oN6PyR7iELLPW
xCrNNm6XvsH79Imv/BP9+f4vwzX3YqVcWg5Noh53VxEZvAPKvCzRWXZFeYff39dC
ySBdJCHe7DCp8826SSMzkqDfrehXww3lq8KD3uyjOO7cXSe9/qvLzP4XlyoOSr9n
gjGrA7Of+/5C9y2yaEQYSkGIr0dsXyLYiDg0hC0N9CWfGLJo8z5oRyXiffzNtNuv
5qf+dmKcChS0Eu1cBSq/XJ5jvV2gHeLXNB3JcSu8cQSKR93lFC0YjQ==
=85fj
-----END PGP SIGNATURE-----

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

[Michael Ansel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Whoops:
- --client-cert-not-required
is also on the server command line

Michael Ansel wrote:

>> On Mon, 10 Mar 2008, Michael Ansel wrote:
>
>>> So, in the interest of all Duke-Linux users, is there any University
>>> policy preventing us from setting up an openvpn server that uses the
>>> Kerberos to authenticate users? Maybe set a bandwidth cap so you don't
>>> top your personal 5G upload limit? Or, set one up, and then convince the
>>> University to sanction it and remove the upload limit...
>
>
> Okay, so hard at work trying to figure this one out, but not exactly
> sure where to go. I'm trying to eliminate client-side certificates and
> only use a local authentication module (currently set to allow any
> user/pass, but that can be replaced with pam-krb5). However, something
> is failing at the final routing stage (after I'm all connected). I can
> ping 10.8.0.1, but nothing else. I'm turning the firewall back on for
> now, so you won't be able to connect to my box, but if somebody wants to
> work on it tomorrow, I'll be happy to open the VPN port up for you to
> check it out.
>
>
> Thanks, and hope we can get this set up and working soon!
>
> Michael
>
>
>
> Server config (server.ovpn): http://pastebin.com/m597d6e5
> Server commandline: openvpn --auth-user-pass-verify /bin/true via-file
> --config server.ovpn
>
> Client commandline: openvpn --client --auth-user-pass --dev tap --ca
> /home/mra13/ca.crt --remote michael-nas.dorm.duke.edu --comp-lzo
> route del default ; route add default 10.8.0.10
> 10.8.0.10 is the remote end of the PTP link according to the client output.
>
> Server Output:
> Tue Mar 11 01:34:01 2008 152.3.66.208:1194 MULTI: bad source address
> from client [152.3.66.208], packet dropped
> ....

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBR9Yb3nlxmnp6j2qxAQKwngf/SdKetfzrbViau+FMH/8SbJsxvoH7oc+S
3U62f9aiEmaRgpxhVNzAGCGItSXo26DXCQP32Cu7EhTMFePjls9N7dqNFtBS0Si4
r0wsh9+y4M1PE3xdbXlNC7S7htP8ffLTkst1RycJn42S8oRNS6wZlC4+YQIGP23m
l0WvcUuQyeBzeCAKxInvBXbCLld5VOqCA/0xpSOuAX7EZE+7foMAxKVT4YHJap1k
gyLwydAGi4LhDOzlqAdgEE+G4tMJDHazuAcJc6y+jLFWp2ySS/RE/bI/dHD9eUyY
OPPKJqt9jvFi8g5RdPKpECVZIe8wuyX/xamX9vlLABoORRjEI+Tosw==
=FkW0
-----END PGP SIGNATURE-----

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

[Robert G. Brown]

On Mon, 10 Mar 2008, Nadeem Kolia wrote:

> I've (just) gotten both Cisco's vpnclient and vpnc to work on my laptop at
> home. I use Gentoo, but I know most others on this list don't, so I'll try to
> leave the Gentoo specific stuff out.
>
> ($ commands are run as root, # as user)
>
> VPNC
>
> 1) Kernel Configuration
>
> Make sure the kernel has Universal TUN/TAP device driver support built in or
> loaded as a module. You probably already have this, but just to make sure you
> can check if its built in with:
> # dmesg | grep TUN
> tun: Universal TUN/TAP device driver, 1.6
>
> or as a module with:
> $ modprobe tun
> $ lsmod
> Module                  Size  Used by
> tun                     7296  0
>
> 2) Install VPNC
>
> VPNC must be installed with support for hybrid authentication (I belive
> vpnc-0.5.0+ have this option). Most distributions should install vpnc with
> this enabled.

Actually, fedora does not because (as noted on the vpnc primary site)
they are in yet another snit about whether openssl's license is GPL
compatible. So they won't/can't build openssl hybrid support into vpnc
and distribute it, probably more won't than can't.

SO, I went and got the 0.5.1 sources and built them with openssl
support, perfectly legal and all that.  I then precisely followed your
path below.

> 3) Generate a root certificate from OIT's rootcert:
> $ openssl x509 -in rootcert -inform der -out /etc/ssl/certs/duke.pem

This failed on the rootcert in the windows VPN zipfile, but succeeded on
the rootcert in my last functioning vpnclient download.  I had to create
the /etc/ssl/certs path.  The vpnc documentation says that Sean's method
should work as well.

> 4) Generate vpnc configuration file from OIT's profile:
> $ pcf2vpnc duke-broadband.pcf /etc/vpnc/default.conf

Already had done this.

> 5) Edit the configuration file so vpnc knows where to find the certificate
> you generated in step 3:
> $ echo "CA-File /etc/ssl/certs/duke.pem" >> /etc/vpnc/default.conf

Did this.

> 6) Start vpnc:
> $ vpnc

Sure, although I had to do it as root.  It refused to bind to the
network otherwise.  It then went off to duke-vpn-public.netcom.duke.edu,
gave me exactly the same prompts as before and failed, exactly as
before.  So now I've failed with two builds -- Sean's and my own, with
my own being the very latest.  Unfortunately, I get absolutely no
diagnostics beyond:

rgb@cain|B:1042#./vpnc --auth-mode hybrid
Enter username for duke-vpn-public.netcom.duke.edu: rgb
Enter password for rgb@...:
./vpnc: no response from target

(after what feels like a short timeout of 20 seconds or so).

Conclusion:  vpnc does not like me.  And yes, one more hour down the
drain.  The only thing I haven't tried is grabbing an even more recent
copy of a duke vpnclient to see if their rootcert has changed or the
like.

> Cisco's VPN Client
>
> 1) Compile/install vpnclient.
>
> As mentioned previously on the list, don't use OIT's version, rather get the
> latest version offered/supported by your distribution. I wasn't able to
> download the client directly from cisco's website, though I was under the
> impression that it was free, but was able to find the version portage
> (Gentoo's package manager) wanted with a quick google search.

It isn't free.  That's why you can't download it directly.

In fact, if one actually reads its license.txt (which is quite
humorous):

4.  You may not transfer the Software to any third party without the
express written permission of Cisco Systems.  For permitted transfers,
you may not export the Software to any country for which the United
States requires any export license or other governmental approval at the
time of export without first obtaining the requisite license and/or
approval.  Furthermore, you may not export the Software in violation of
any export control laws of the United States or any other country.

5.  You may not modify, translate, decompile, disassemble, use for any
competitive analysis, reverse engineer, distribute, or create derivative
works from, the Software or any accompanying documentation or any copy
thereof, in whole or in part.

SO, your source was violating the license provision 4 by redistributing
it, unless he or she had written permission which I doubt.  If it
actually worked, they were violating license provision 5.

That's the humorous part.  Read it like this:

4. You may not have this software.  Only we can distribute it, and we
won't.  Unless you make us, are willing to pay us on the side, have a
service contract with us, or something, we'd really you rather not.
Also, don't even THINK about carrying your laptop overseas once it is
installed.

5. If you ignore our advice in 4, and actually pester us to the point
where we give you a copy of our sources, which have to be built against
your kernel, well, it won't work.  We guarantee it, because we
outsourced the maintenance of the entire package to a bunch of
incompetent clowns -- we don't want OUR systems engineers to be saddled
with actually making sure our VPN will build against any particular
kernel in linux.  That's too much like work.  So when you are forced to
hack the sources to make it work, well, you've violated the software
license and have to give it back.  Especially if you are a systems
administrator capable of fixing the software who is building it to
redistribute it to all your users.  Did you get permission in writing?
I didn't think so.

Give it back, right now!  No vpn for you!

I mean, seriously -- the Cisco VPN isn't a product, it is a joke.  They
sell you the VPN, but then won't provide you with working software to
actually use it.  They won't make it work, but will prohibit you from
making it work.

This is the work of some demented systems engineer who used to work at
Cisco and got really pissed off.  He carefully crafted this some seven
or eight years ago after making several bets with friends about how long
it would take Cisco to notice.  Now he does standup comedy routines in
taverns in the southwest, working behind a cage so he doesn't get cut by
the glass from thrown bottles -- and considers himself more fortunate
than he was working at Cisco.  He's long since drunk all the proceeds
from his well-won wagers.

> 2) After installation, make sure the installed modules have been loaded.
>
> 3) Download OIT's vpnclient for Linux:
> http://www.oit.duke.edu/network/remote/vpn/linux.html
>
> 4) Import the root certificate:
> # /opt/cisco-vpnclient/bin/cisco_cert_mgr -R -op import
>
> 5) Copy the .pcf files to cisco vpnclient configuration directory:
> $ cp duke*.pcf /etc/opt/cisco-vpnclient/Profiles/
>
> 6) Run vpnclient
> # vpnclient connect duke-broadband

Yeah, yeah -- been there, done that, patching the vpnclient myself
(starting from a hard-won legally downloaded client that I got by
spending several hours working on the cisco site until I finally got it
to acknowledge that I might -- just might -- be entitled to download a
copy).

I'm done with it.  I might grab the current OIT package just to get the
rootcert to be absolutely certain that it is correct, since openssl
barfed on the windows package rootcert when I tried to use it to
generate the pem, but honestly I'm so sick of the whole thing I can't
see straight.  I want to just use openvpn from inside network manager.
Even vpnc alleges that one has to set up routing, nameservice, and so on
by hand even if you get it to work, although I have yet to get it to
work to the point where I can find out.  At least vpnclient managed all
of that for you, once you hacked it to where it would work.

I'm not interested.  I want to click a button in userspace, have my
authentication tokens retrieved automagically from my keyring, connect
to the vpn transparently with all routing etc. invisibly handled, and
exit back to my primary network just as gracefully.

Thanks, though -- I appreciate the response and help even though it
didn't work.

    rgb

>
> - Nadeem
>
> _______________________________________________
> 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
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, 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
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, Michael Ansel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> On Mon, 10 Mar 2008, Michael Ansel wrote:
>>
>>> So, in the interest of all Duke-Linux users, is there any University
>>> policy preventing us from setting up an openvpn server that uses the
>>> Kerberos to authenticate users? Maybe set a bandwidth cap so you don't
>>> top your personal 5G upload limit? Or, set one up, and then convince the
>>> University to sanction it and remove the upload limit...
>
>
> Okay, so hard at work trying to figure this one out, but not exactly
> sure where to go. I'm trying to eliminate client-side certificates and
> only use a local authentication module (currently set to allow any
> user/pass, but that can be replaced with pam-krb5). However, something
> is failing at the final routing stage (after I'm all connected). I can
> ping 10.8.0.1, but nothing else. I'm turning the firewall back on for
> now, so you won't be able to connect to my box, but if somebody wants to
> work on it tomorrow, I'll be happy to open the VPN port up for you to
> check it out.

Client side certs or preshared keys are your friend -- they are one of
the only good things about ipsec (mixed in with the many, many bad
things, like the fact that a bug crashes the kernel and an exploit gives
the cracker an instant root shell).  There's a cute little article here:

  http://www.linux.com/feature/48330?page=2

that reviews many of them, and touts the significant benefits of having
an actual client that can be wrapped up with certificates.  Remember,
Duke CAN arrange to distribute the certificates through a netid-secured
channel.

    rgb

> Thanks, and hope we can get this set up and working soon!
>
> Michael
>
>
>
> Server config (server.ovpn): http://pastebin.com/m597d6e5
> Server commandline: openvpn --auth-user-pass-verify /bin/true via-file
> - --config server.ovpn
>
> Client commandline: openvpn --client --auth-user-pass --dev tap --ca
> /home/mra13/ca.crt --remote michael-nas.dorm.duke.edu --comp-lzo
> route del default ; route add default 10.8.0.10
> 10.8.0.10 is the remote end of the PTP link according to the client output.
>
> Server Output:
> Tue Mar 11 01:34:01 2008 152.3.66.208:1194 MULTI: bad source address
> from client [152.3.66.208], packet dropped
> ....
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iQEVAwUBR9YbUXlxmnp6j2qxAQIDgAf7By4Jh2I/jY9+GRVlsyADSju0nRs7kJ+C
> liqwaoRaKIbSalQdYukOrngYLnkBuipiKwwhDNfUBkpvxehAk/4oN6PyR7iELLPW
> xCrNNm6XvsH79Imv/BP9+f4vwzX3YqVcWg5Noh53VxEZvAPKvCzRWXZFeYff39dC
> ySBdJCHe7DCp8826SSMzkqDfrehXww3lq8KD3uyjOO7cXSe9/qvLzP4XlyoOSr9n
> gjGrA7Of+/5C9y2yaEQYSkGIr0dsXyLYiDg0hC0N9CWfGLJo8z5oRyXiffzNtNuv
> 5qf+dmKcChS0Eu1cBSq/XJ5jvV2gHeLXNB3JcSu8cQSKR93lFC0YjQ==
> =85fj
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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
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

[Brian Johnson-10]

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.

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.

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

--
Brian Johnson
"And I will be even more undignified than this, and will be humble in my own sight." (2 Samuel 6:22)
_______________________________________________
Dulug mailing list
Dulug@...
https://lists.dulug.duke.edu/mailman/listinfo/dulug

[seth vidal-3]

On Tue, 2008-03-11 at 02:28 -0400, Robert G. Brown wrote:

> Actually, fedora does not because (as noted on the vpnc primary site)
> they are in yet another snit about whether openssl's license is GPL
> compatible. So they won't/can't build openssl hybrid support into vpnc
> and distribute it, probably more won't than can't.

openssl's license is incompatible with the gpl. You need to have a
specific exception added to the license to allow it.
It's more cannot than will not.

-sv


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

[Sean Dilda-2]

Robert G. Brown wrote:

> It then runs, but laughs at me:
>
> rgb@cain|B:1036#vpnc
> Enter username for duke-vpn-public.netcom.duke.edu: rgb
> Enter password for rgb@...: /usr/sbin/vpnc:
> no response from target
>

Whenever I see an error message like that, I have to ask:  Is there any
chance there's a firewall blocking you?  Perhaps whatever ISP you're
connecting through is blocking Cisco VPN traffic (udp port 500) or all
UDP traffic?

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

[Michael Ansel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Thats fantastic news! Is there anything we as Linux users can do to make
this as easy to use and compatible as possible? Also, when do you guys
think it will be up and running? One more question, just for my
curiosity: why did you choose closed vs open source? Was it easier, or
did it just come with a support contract? Thanks! I look forward to
having (proper) VPN access instead of private tunneling! :P

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBR9awu3lxmnp6j2qxAQIbCAf/W1/ipb6IC5UINTQI3mrLsV1DUouROby0
PtuOFzRK7lCnvMSnt83Q0J7hJChJld33YTrnIgVmcWjStY1+z+0G6SvbiXp8dqNZ
Ly+tKMdLja2JVcXm8bmjV3ArqTEYN65MhumK2pyeKsyaT8+c/O2/tdCQ3qtauv19
FHQa/o54y2gwopC93OH655gX5lqEyYtumdZqUXXU4fcsOA8No904b7u5XRs5KSmz
ILNpMQRMzly7X3Wab3WCrU9eglpbYFV1c0XzT653AUSNY1KGX5n6ZQS2xWg05XBC
kkvQdJ+lgURBf3ymeB/L58xjwtX5qxQbJLW0L67CxR0vhMR0XPhrzA==
=yT1H
-----END PGP SIGNATURE-----

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

[Aleksandr Andreev]

This might sound totally stupid, but are you running through a router?
My router at home had port 500 blocked. Once I opened it up, vpn
worked fine.

A

2008/3/11, Sean Dilda <sean@...>:

> Robert G. Brown wrote:
>
>  > It then runs, but laughs at me:
>  >
>  > rgb@cain|B:1036#vpnc
>  > Enter username for duke-vpn-public.netcom.duke.edu: rgb
>  > Enter password for rgb@...: /usr/sbin/vpnc:
>  > no response from target
>  >
>
>
> Whenever I see an error message like that, I have to ask:  Is there any
>  chance there's a firewall blocking you?  Perhaps whatever ISP you're
>  connecting through is blocking Cisco VPN traffic (udp port 500) or all
>  UDP traffic?
>
>
>  _______________________________________________
>  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 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
>>
>
>
>
>

--
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 02:28 -0400, Robert G. Brown wrote:
>
>> Actually, fedora does not because (as noted on the vpnc primary site)
>> they are in yet another snit about whether openssl's license is GPL
>> compatible. So they won't/can't build openssl hybrid support into vpnc
>> and distribute it, probably more won't than can't.
>
> openssl's license is incompatible with the gpl. You need to have a
> specific exception added to the license to allow it.
> It's more cannot than will not.

So how does openvpn manage it?  Python?  XML Security Library?  There
seem to be quite a few tools that are built CLAIMING to have openssl
integration or that use the openssl library, and openvpn is GPL.

I'm not arguing, mind you, just trying to learn.  Trying not to be
cranky as my day wastes away and learn.

    rgb

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