Hello, I would like to know, if anyone beside of me is interested in enabling "Local LAN Access" in the "cisco vpnclient" although a "policy" on the VPN server actually "disables" it. I always found it quite annyoing that I can't connect to my LAN devices (printer, ...) while the tunnel is up and therefore preferred to launch the vpnclient on a separate machine. Due to a severe hardware problem on by separate machine, I'm now forced to run the "vpnclient" on my main machine which made me quite ambitious to work around cisco's "pseudo security feature". The result is an updated "-4.7" ebuild consisting of * the updated ebuild itself * a patch for the kernel module (interceptor.c) which bypasses the "interceptor" for all ip traffic that does not go to / come from the VPN gateway's public IP address * a small script (wrapper around vpnclient) that modifies the routing tables after "vpnclient" has established the tunnel. // requires "sudo" because we need "root access" to // modify the routing tables * an additional config file that defines the "private networks" and the gateway (yes, there is some redundancy here ...) used by each "profile". May I upload/attach this stuff? Cheers, Axel
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 :/
