We already have vpnc. Openconnect is compatible with the Cisco SSL head end. It's already part of the debian packages http://git.infradead.org/users/dwmw2/openconnect.git It would be nice it's part of the gentoo portage too Reproducible: Always Steps to Reproduce: Enhancement request Actual Results: not implemented Expected Results: get it implemented http://packages.debian.org/en/sid/openconnect
Tarball releases of openconnect are at ftp://ftp.infradead.org/pub/openconnect/ You'll probably want NetworkManager-openconnect too, which is in GNOME SVN with the other NetworkManager VPN plugins. It would be useful (but not absolutely required) to make sure you have some of the fixes which are already in OpenSSL upstream, which make DTLS work. DTLS is the TLS-over-UDP protocol which makes the VPN much more efficient (because TCP over TCP sucks). Relevant patches are: http://cvs.openssl.org/chngview?cn=17500 http://cvs.openssl.org/chngview?cn=17505 http://cvs.openssl.org/chngview?cn=18037 The first two are in OpenSSL 0.9.8j and later already; the last is merged more recently and should be in OpenSSL 0.9.8l when it gets released.
Created attachment 198948 [details] net-misc/openconnect-2.01.ebuild This is a first try to create an ebuild for Openconnect VPN client.
Adam's ebuild works for me, though I had to change the name to openconnect-2.10.ebuild first. I wrote this (admittedly crude) startup script to make my setup go: depend() { use net } source /etc/conf.d/openconnect PID="/var/run/openconnect.pid" start() { ebegin "Starting OpenConnect" echo $PASSWORD | /usr/bin/openconnect --no-dtls --user=$USERNAME --authgroup=$AUTHGROUP --no-deflate $SERVER --passwd-on-stdin >& /dev/null & echo $! > $PID sleep 2 # Setup routing for NET in $NETWORKS; do route add -net $NET netmask 255.255.255.0 dev tun0 done eend $? } stop() { ebegin "Stopping OpenConnect" # Teardown routing for NET in $NETWORKS; do route del -net $NET netmask 255.255.255.0 dev tun0 done kill $(cat $PID) eend $? } And /etc/conf.d/openconnect looks like this: USERNAME="someusername" PASSWORD="secretpassword" AUTHGROUP="some_group" SERVER="someserver.domain.org" NETWORKS=" 1.2.3.4 1.2.3.5 1.2.3.6 " It's probably not what everyone would want for their setup, but I thought that I'd post what works for me.
Adam's ebuild works perfectly for me, too, even after I changed to v2.25 (not that I necessarily needed the new features, but I just felt like using the latest).
Adam's ebuild works ok for me for 2.21, but it would be nice to have an official ebuild, one that's maintained, etc. I use openconnect nearly every day. Can't get along without it.
Created attachment 254987 [details] updated ebuild for 2.26 with some modifications Here is an updated ebuild based on Adam's original one (thanks Adam!). Changes are to respect LDFLAGS and CFLAGS, change compiler and ar program names, use pkg-config for SSL library linkage detection and add gconf as a dependency (because Ubuntu and Debian do that). I'd like to point out I'm not a programmer, I'm a sys admin so my approach to writing ebuilds is to apply a square peg to a circular hole until it fits. I also program in Perl... This updated ebuild will be available in my personal overlay as I use this for work: https://github.com/joshuar/ephemeral-gentoo-overlay Regards, Josh
Ebuild for the networkmanager plugin available in bug #346265.
Created attachment 255447 [details] openconnect-2.26-r1.ebuild Hi, I used the existing ebuild, added an init file, config file and a vpnc script file to make it easier to run. Configuration is similar to vpnc. 1) link /etc/init.d/openconnect to /etc/init.d/openconnect.yourvpn 2) Create the folder /etc/openconnect/yourvpn 3) Copy file /etc/openconnect/openconnect/openconnect.conf to /etc/openconnect/yourvpn/yourvpn.conf 4) Copy file /etc/openconnect/openconnect/openconnect.sh to /etc/openconnect/yourvpn/yourvpn.sh 5) Modify the files to fit your needs 6) pre-up, pre-down, post-up, post-down scripts can also be added. Just name them in yurvpn-{preup,predown,postup,postdown}.sh and place them in /etc/openconnect/yourvpn/ 7) Logs can be found in /var/log/openconnect/yourvpn/yourvpn.{err,log} Cheers, Bjoern
Created attachment 255449 [details] openconnect.conf Example config file (net-misc/openconnect/files/openconnect.conf)
Created attachment 255451 [details] openconnect.sh Stolen from vpnc. Script to manage routing and DNS (net-misc/openconnect/files/openconnect.shopenconnect.sh).
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Michał. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Could you please separate the original source code and put your modifications as patches/seperate sources (so we can get it from an official place). It is a vpn client so I want a package that I can check the its trustworthy. Thanks in advance!
(In reply to comment #12) > Could you please separate the original source code and put your modifications > as patches/seperate sources (so we can get it from an official place). > > It is a vpn client so I want a package that I can check the its trustworthy. > > Thanks in advance! The only "changes" to the source done in the ebuild is to the makefile and those changes are mostly cosmetic. See comment #6. You don't need them, but if you remove them, Gentoo QA probably would never accept the ebuild. Bjoern has then provided a *separate* init.d and wrapper script, both of which are provided on top of, completely separate to, and essentially optional to the actual openconnect source. So I'm a little confused by your request. Can you please clarify what you want? Even better, how about contributing what you want?
I understand you did some changes to the Makefile. However that is difficult to track (I can't go through the code, however I would probably be able to use diff with an original package, but this is not something that I want to do over and over again). It is just that if an "official" tarball of openconnect is used, then changed to fit on gentoo with patches, that this seems more correct in my eyes and is more trustworthy. Modifications are easy to see. Also in this way tarballs from different locations can still be used. And will match the same md5/sha checksums.
(In reply to comment #14) > I understand you did some changes to the Makefile. > However that is difficult to track (I can't go through the code, however I > would probably be able to use diff with an original package, but this is not > something that I want to do over and over again). > It is just that if an "official" tarball of openconnect is used, then changed > to fit on gentoo with patches, that this seems more correct in my eyes and is > more trustworthy. Modifications are easy to see. > Also in this way tarballs from different locations can still be used. And will > match the same md5/sha checksums. What is the difference between calling patch or calling sed *after* the *unmodified* source package is unpacked? What you are requesting is already in place. Gentoo downloads from upstream (as in this case) or mirrors (for packages in the official tree) the unmodified source package. The ebuild applies a bunch of modifications to the source and builds it. Gentoo doesn't provide a modified source package. You could download the source package from Gentoo infrastructure (if it was hosted there) and from the upstream repo and the sums will match. Have you actually tried to use the ebuild attached to this bug? It will download the source from upstream. Ideally, for your particular needs, you should be building from source yourself, not using somebody else's package or build script. There is a level of trust in using distribution packages. You need to trust the developers and contributors of the distribution to do the right thing. If you can't, which is what you are implying, you shouldn't use a distribution. Again, please feel free to contribute. I'm quite happy with the ebuild here and have copied it into my personal overlay for actual, real-world use. Regards, Josh
I've merged the change to use pkgconfig for openssl. The CFLAGS and LDFLAGS bits could almost certainly be made to do the right thing out of the box, too. Please submit patches...
> What is the difference between calling patch or calling sed *after* the > *unmodified* source package is unpacked? What you are requesting is already in > place. I had interpreted that it was a modified tarball. If not then everything is ok:) > I'm quite happy with the ebuild here > and have copied it into my personal overlay for actual, real-world use. I use it in the real world too... isn't that awesome? :) Otherwhise I probably wouldn't bother. > There is a level > of trust in using distribution packages. True. However being a little paranoid is never a bad idea ^^ In my case there is a certain level of trust in the official portage tree. I am however rather careful with ebuilds supplied seperately. So please don't take my comments as an offense.
Well apparently my address got lost in the CC so my two cent to sed and patch: IMHO is a patch favored over sed when it comes to the integration into the main tree - or at least it was. I wonder why the proposed changes will not make it into the portage main tree, any comments on this? Cheers, Bjoern
(In reply to comment #18) > Well apparently my address got lost in the CC so my two cent to sed and patch: > > IMHO is a patch favored over sed when it comes to the integration into the main > tree - or at least it was. > > I wonder why the proposed changes will not make it into the portage main tree, > any comments on this? > > Cheers, > Bjoern The package is assigned to <maintainer-wanted@gentoo.org>, so it's simple: no developer has decided to take up the package. As per comment 11 someone (non-dev) could Sunrise it, or someone could propose to proxy-maintain it.
Created attachment 271923 [details] openconnect init script Apparently I forgot to attach the init script.... here it is... Better later then never ;-) Cheers, Bjoern
openconnect.sh script doesn't seem to to work but the one provided from vpnc-0.5.3 works. openconnect -s /etc/vpnc/vpnc-script -u [USER] [HOST]
Created attachment 273809 [details] ebuild for openconnect 3.02 Here is an updated ebuild for version 3.02. It installs the vpnc compatible script provided by upstream here: http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob_plain/HEAD:/vpnc-script That may fix some of the problems people are encountering. I haven't incorporated Bjoern's init script as I don't use openconnect as a service. Regards, Josh
(In reply to comment #22) > That may fix some of the problems people are encountering. I haven't > incorporated Bjoern's init script as I don't use openconnect as a service. The init script is essential for the ebuild. Other vpn software provides this (vpnc, anyconnect, openvpn) and there's no reason why this should not too.
I'm confused. Do you have an init script for 'eth0' too? Why would you have one for 'vpn0'? Why wouldn't this be part of the *network* scripting?
(In reply to comment #24) > I'm confused. Do you have an init script for 'eth0' too? Why would you have one > for 'vpn0'? Why wouldn't this be part of the *network* scripting? Sure there is an inint script for eth0: ln -s net.lo net.eth0 How do you think you start an service on boot? Via cron? "@reboot /path/to/service" ? I totally agree, that the init script is essential for a tool which can serve as a service. No one is forced to use the init script to start openconnect at boot (when you use openconnect e.g via NetworkManager). But bringing up a service at boot time is generally done via init scripts... Kind regards, Bjoern
networkmanager-openconnect-0.8.4 requires that openconnect install openconnect.pc, otherwise it will refuse to build. Please change the ebuild to install openconnect.pc. Here's what happens when I emerge net-misc/networkmanager-openconnect-0.8.4 with net-misc/openconnect-3.02 installed: checking if msgfmt accepts -c... yes checking for gmsgfmt... (cached) /usr/bin/gmsgfmt checking for xgettext... (cached) /usr/bin/xgettext checking for x86_64-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GTHREAD... yes checking for DBUS... yes checking for OPENCONNECT... no configure: error: Package requirements (openconnect) were not met: No package 'openconnect' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables OPENCONNECT_CFLAGS and OPENCONNECT_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-misc/networkmanager-openconnect-0.8.4/work/NetworkManager-openconnect-0.8.4/config.log * ERROR: net-misc/networkmanager-openconnect-0.8.4 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 2433: Called econf '--disable-more-warnings' '--without-gnome' '--enable-nls' * ebuild.sh, line 557: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of 'emerge --info =net-misc/networkmanager-openconnect-0.8.4', * the complete build log and the output of 'emerge -pqv =net-misc/networkmanager-openconnect-0.8.4'. * This ebuild is from an overlay: '/usr/local/portage-overlay/' * The complete build log is located at '/var/tmp/portage/net-misc/networkmanager-openconnect-0.8.4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/networkmanager-openconnect-0.8.4/temp/environment'. * S: '/var/tmp/portage/net-misc/networkmanager-openconnect-0.8.4/work/NetworkManager-openconnect-0.8.4' >>> Failed to emerge net-misc/networkmanager-openconnect-0.8.4, Log file:
Created attachment 274157 [details] openconnect-3.02.ebuild proper Ebuild from Joshua Rich with the following modifications: - Re added init script - Re added default configuration - checking for TUN/TAP Kernel support Cheers, Bjoern
(In reply to comment #26) > networkmanager-openconnect-0.8.4 requires that openconnect install > openconnect.pc, otherwise it will refuse to build. Please change the ebuild to > install openconnect.pc. > I'll see what I can do.
Created attachment 274161 [details] openconnect-3.02-r1.ebuild I just added emake DESTDIR="${D}" install-lib || die "Faild to install libs" Don't know if this is the gentooish way, but at least networkmanager-openconnect-0.8.4 now no longer fails because of missing libs from openconnect ;-) It now fails for me with: main.c:39:32: fatal error: gconf/gconf-client.h: No such file or directory compilation terminated. But I guess this is not related to openconnect and should be tracked on bug #346265 Cheers, Bjoern
http://www.infradead.org/openconnect.html It's now up to version 3.11. http://gpo.zugaina.org/net-misc/openconnect I see a couple of old versions in overlays, but nothing that looks like someone is keeping it current. I'll install from source.
(In reply to comment #30) > http://www.infradead.org/openconnect.html > It's now up to version 3.11. > > http://gpo.zugaina.org/net-misc/openconnect > I see a couple of old versions in overlays, but nothing that looks like someone > is keeping it current. > > I'll install from source. Well, you could simply try to version bump this ebuild, which provides you with everything you need and report back if it is working. This would help others as well. Cheers, Bjoern
I'll take over maintenance of this package and add it to the tree shortly.
(In reply to comment #32) > I'll take over maintenance of this package and add it to the tree shortly. Great news, Thanks! Cheers, Bjoern
I have now added version 3.11 to the tree. Please test it, as I do not even have means to do it myself. If you find any bugs, please let me know. Thank you very much for everyone who contributed!
network-manager integration will follow shortly.
it works for me on amd64 just as well as the previous ebuild i grabbed from here. thanks! 3.11 also fixed the /etc directory naming and came with it's own run script. i'm having huge problems on our vpn with UDP packets, however. others on our VPN do not have this problem, even one running openconnect on gentoo. if anyone can point me in the right direction on that one it'd be great. also, how does one go about using the init script? it uses $SERVER, $VPNOPTS, etc variables. where is the best place to define those so they are available to the init script at start? once network-manager module gets added to the tree does that init script still get used? thanks for getting this into the tree Robert!
(In reply to comment #36) > i'm having huge problems on our vpn with UDP packets, however. others on our > VPN do not have this problem, even one running openconnect on gentoo. > if anyone can point me in the right direction on that one it'd be great. Give the pixie a gold coin.
(In reply to comment #36) > also, how does one go about using the init script? it uses $SERVER, $VPNOPTS, > etc variables. where is the best place to define those so they are available > to the init script at start? /etc/conf.d/openconnect ? > once network-manager module gets added to the tree does that init script still > get used? Not everybody is going to use network-manager, so the init script would be definitely needed. Thanks, /Adam
okay, i was wrong. the new ebuild in the tree does not work out of the box for me. the openconnect.sh script has an extra newline at the end which prevents me from geting a webDM cookie for some reason. that's the only difference over the openconnect.sh script which is posted in this bug. using the script posted here works and the ebuild supplied init script works after updating /etc/conf.d/openconnect, duh. (thanks adam)
(In reply to comment #37) > (In reply to comment #36) > > i'm having huge problems on our vpn with UDP packets, however. others on our > > VPN do not have this problem, even one running openconnect on gentoo. > > if anyone can point me in the right direction on that one it'd be great. > > Give the pixie a gold coin. i'm SO frustrated by this thing that i'm replying to this only in hopes that this is supposed to remind me that i'm missing something obvious.
(In reply to comment #40) > (In reply to comment #37) > > (In reply to comment #36) > > > i'm having huge problems on our vpn with UDP packets, however. others on our > > > VPN do not have this problem, even one running openconnect on gentoo. > > > if anyone can point me in the right direction on that one it'd be great. > > > > Give the pixie a gold coin. > > i'm SO frustrated by this thing that i'm replying to this only in hopes that > this is supposed to remind me that i'm missing something obvious. It is, yes. It's my stock response. The explanation is as follows: I had "huge problems with UDP packets" once. The problem was that every time I tried to send a UDP packet, a pixie jumped out from under my desk and ran away with my laptop. I was eventually able to dissuade him from this behaviour by giving him a gold coin. If that *wasn't* your problem, you need to describe your issue with enough detail that I know it *wasn't* a pixie. As a general rule: When reporting an issue, read over your report and give it the "pixie test". If someone reading your report could reasonably blame it on a pixie as I did, then try giving more information :) So let's start with some questions... do you mean UDP packets as in VPN-over-UDP (DTLS), or do you mean UDP packets *inside* the VPN tunnel? Do you have tcpdump captures from both ends showing the packets that either get through or fail? Is it only packets of certain *sizes* that fail? I'm sure I'll have more once you actually start to tell me what the problem *is*, but I suspect it lives somewhere other than in this bug. Can you send mail to openconnect-devel@lists.infradead.org and I'll try to help?
Mhh, why did you cripple the init script in a way that it is no longer possible to configure multiple configurations? I build the init script similar to the one from openvpn so it is possible to have multiple configurations. You are not gonna tell me, that this is a feature to only have ONE server configured in /etc/init.d/openconnect, do you? The ebuild is not usable in this way for me and i would consider it NOT WORKING. Cheers, Bjoern
(In reply to comment #42) > Mhh, why did you cripple the init script in a way that it is no longer possible > to configure multiple configurations? > I build the init script similar to the one from openvpn so it is possible to > have multiple configurations. > > You are not gonna tell me, that this is a feature to only have ONE server > configured in /etc/init.d/openconnect, do you? > > The ebuild is not usable in this way for me and i would consider it NOT > WORKING. > > Cheers, > Bjoern Yeah, you're right. I didn't think about multiple instances. I'll update init script and bump revision.
the init script in non -r1 ebuild does not kill the connection when /etc/init.d/openconnect stop is issued. it says [ ok ] but the connection remains up. have to use killall openconnect to bring it down
> Yeah, you're right. I didn't think about multiple instances. I'll update init > script and bump revision. Thanks for taking this into account. Any news on this? Cheers, Bjoern
i looked into the init script not bringing down the connection just a bit more. it creates the PID file at start. but this doesn't bring down the connection: start-stop-daemon --quiet --pidfile /var/run/openconnect.pid --stop /usr/bin/openconnect eend $? afterwards, the PID file is gone
