Summary: | net-misc/cisco-vpnclient-3des-4.7 LAN ACCESS patch | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Axel Dyks <XL> |
Component: | New packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | mmokrejs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The modified ebuild for 4.7
The kernel patch for 4.7 ... The wrapper script (hopefully version independent) ... A config file sample (hopefully version independent) ... A "lan access" ebuidl for version "4.8" The "up-to-2.6.22" patch from tuxx-home.at by Alexander Griesser An updated version of my "lan-access.patch" meant to be applied on top of the "tuxx-at 2.6.X" patch ... An updated ebuild for 4.8 that applies "2.6.X.patch" and "lan-access-2.6.X.patch" |
Description
Axel Dyks
2007-06-21 02:38:30 UTC
I see no reason why you couldn't/shouldn't, but I likely won't accept it into the tree simply because I'd prefer not have to maintain the functionality for eternity. I do like it, but unless you can poke it out as a single patch and plan on sticking around to maintain it, I'd rather not add it. If you feel you'd be willing to keep up with the patch (if it needs it) for future versions, then I see nothing really stopping me from adding it, realizing that if you disappear, it might get dropped on future versions. Just let me know and go ahead and attach the patch. At the very least, someone else might be interested and would like to see your work. I'm curious myself. Created attachment 122726 [details]
The modified ebuild for 4.7
Created attachment 122727 [details]
The kernel patch for 4.7 ...
Created attachment 122729 [details]
The wrapper script (hopefully version independent) ...
Created attachment 122730 [details]
A config file sample (hopefully version independent) ...
All files beside of the ebuild shall reside in the "files" subfolder.
In reply to comment #1: Don't know how much it takes to adjust the kernel module patch for other/newer version of the vpnclient and/or the kernel. The other stuff is more or less version independent. I currently do not have the 4.8 sources at hand, otherwise I would have had a look into it already. Anyway, if there are more users out there who enjoy this new "feature" as much as I do, I'd propably like to maintain the patch -- at least for a while ... So lets wait for the feedback. :-) Axel Created attachment 122763 [details]
A "lan access" ebuidl for version "4.8"
Luckily "interceptor.c" hasn't changed from 4.7 to 4.8. So here we are.
The tunnel (using 4.8) is up while I'm writing these lines.
Axel
P.S.: Though an RDP connection to a client behind the gateway stayed up
for hours using "4.7 lanaccess", I've had several "hangs" with "ssh"
sessions run over the tunnel.
Sometimes the problem occured after a few minutes, sometimes the
session stayed responsive for more than an hour.
Can't say whether this is due to my patch or not, but I guess it's not.
The "ssh hangs" are obviously caused by an MTU problem. I've reduced the (eth0) MTU on the machine I'm connecting to behind the tunnel and had no problem with an MTU of 1000. // My test scenario is bulding glibc within an ssh session // on the remote computer which outputs some lengthy lines. // "Hanging" almost always occurs at the same point, a very // long sed expression being echoed to the terminal... I've tried to reduce the MTU step by step starting from 1500 to lower values, but so far nothing worked in the range from 1340 to 1500 (but 1000 did, see above). Note that cisco's vpnclient sets the MTU on cipsec0 to 1356 which is on the (ssh) client side and not on the (ssh) server side where I'm currently trying different values. Do you (Chris or anybody) know a command that displays the current MTU of a TCP socket? As far as I've understood the value should be automatically adjusted by using PMTU discovery. Axel Hello, I'm now using the "lan access" feature for about 14 days without noticing any problems that are likely to be caused by the patch. I think that we could even unconditionally patch "interceptor.c", because of the additional code not being used unless a "gateway" has been passed from user space. The "ssh hangs" do not occur, if MTU is reduced to 1300 on the remote (sshd) side. So it seems that PMTU discovery isn't reliable on my tunnel which I'm currently blaming the gateway/firewall for. May I expect to get feedback on this "feature" or shall I assume that nobody beside of me has got an interest? At least as long as "vpnc" (stable) doesn't support certificates, hybrid authentication, re-keying and IPSEC over TCP/IP I would assume that many -- including me -- are stuck with cisco's VPN client ... Cheers, Axel Created attachment 128453 [details, diff]
The "up-to-2.6.22" patch from tuxx-home.at by Alexander Griesser
Created attachment 128455 [details, diff]
An updated version of my "lan-access.patch" meant to be applied on top of the "tuxx-at 2.6.X" patch ...
Created attachment 128457 [details]
An updated ebuild for 4.8 that applies "2.6.X.patch" and "lan-access-2.6.X.patch"
Apart from the two patches this ebuild requires the previously uploaded
"lan-access config sample" as well as the "wrapper script" to be
available in the "files" sub-folder.
Cheers,
Axel
Well, this allows one to violate a company's security policy, so I can't really put it into the tree with good confidence. That being said, I'm retiring from Gentoo, so maybe the next guy will accept it. (In reply to comment #13) > Well, this allows one to violate a company's security policy, so I can't really > put it into the tree with good confidence. > This is wontfix then for official main tree :/ |