Description of problem: If a user is connecting with VPNC via NetworkManager and his or her token is out of sync, the server will prompt for Next Token. NetworkManager misinterprets this response and reports a failed connection. Version-Release number of selected component (if applicable): NetworkManager-vpnc-0.7.997-1.el6.rhis.x86_64 How reproducible: Always when token is out of sync Steps to Reproduce: 1. Obtain a user token that is out of sync 2. Attempt to connect to the VPN connection Actual results: Connection failed Expected results: A new prompt should appear prompting for next token code Additional info: This build is not part of RHEL6, but the package has been maintained by Dan Williams.
Given that NM-vpnc isn't part of RHEL6, best thing to do would be to move this bug to Fedora where we can fix it. When it gets fixed, then the NM-vpnc builds would show up in EPEL.
This of course also depends on vpnc being able to handle the next token code stuff, which I don't think it does. NM just pushes the PIN + token code down to vpn, which then attempts to connect with it. Obviously in the end you just need to resync your token to the access concentrator.
This theoretically affects NetworkManager-openswan (official RHEL6 package) as well. Whether openswan can handle next token mode is another story, but there is no facility for any VPN client to handle this in NM (also including fedora package NetworkManager-openvpn)
Dan, Can I get a status update on this? Is there any upcoming plan to work on this issue?
There are vague plans to work on this; it requires a rework of some internal NetworkManager VPN handling code to allow the plugins themselves to request secrets from the user during connection, which is not how it currently works. There's no staffing for that though, given the other various RHEL/Fedora priorities that are on the stack. Patches accepted, and I can certainly tell somebody what the general architecture should be; I've updated the TODO file in NM git with an approach to this problem.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Re-opening since we're working on this finally.
*** Bug 679869 has been marked as a duplicate of this bug. ***
And hit upstream a month ago and it's in F20+ builds.