Usernames should not include @ signs. about get-a-robot-vpnc HOT 12 OPEN

My company uses the format username@tunnelname as the username to identify both 
the user and the 
desired vpn tunnel, of which there are several, so I can't avoid having an @ in 
the username. Is this 
relatively easy to fix?

Thanks

-bump-

Have you tried to connect with both the @ sign and without it? Does your device 
meet
all the other requirements? If so, attach your
"/data/data/org.codeandroid.vpnc_frontend/files/lastConnection.log" after 
trying to
connect and failing... we'll see what's going on.

I just want to add, that connecting to a vpn with @ in the username works for 
me.

I cleaned up the log file (obviously) so as not to reveal anything, but I will 
say
the following:

   * my shared password contains the characters $, / and &. I'm not sure if those
could be messing something up. I suspect they are as when I tried an incorrect
password without these characters it seemed like it got farther.

   * my username contains an @ sign.

   * my user password contains a $ character.

anyway, here's the output:

/data/data/org.codeandroid.vpnc_frontend/files/vpnc --script
/data/data/org.codeandroid.vpnc_frontend/files/vpnc-script --no-detach
Enter IPSec gateway address:
vpn.mycompany.com
Enter IPSec ID for vpn.mycompany.com:
[my shared-username]
Enter IPSec secret for [my shared-username]@vpn.mycompany.com:
[my shared username password]
Enter username for vpn.mycompany.com:
[my username]
Enter password for [my username]@vpn.mycompany.com:
********



process stderr


vpnc still trying to connect. Will check again in 500 milliseconds
[ many repeating lines of the same thing ]
no response from target

process stderr  no response from target

process had died, return as failed connection

Yes, just as a quick followup, if I use a group password that does not have any 
funny
characters, I get this:

hash comparison failed:  (ISAKMP_N_AUTHENTICATION_FAILED)(24)
check group password!

process stderr  hash comparison failed:  (ISAKMP_N_AUTHENTICATION_FAILED)(24)
check group password!

Maybe the special characters need to be escaped better when we pass them to the 
script?

Are you saying that you're using an invalid group password (with no special 
chars)
and get this? Or if it's a valid (though alternative) group password, then why 
would
you get "hash comparison failed"? I have a hard time reproducing this given 
that I
don't have access to a VPN server with special characters in any id or 
password. I
assume you can verify that the Java code passes the values on correctly (I don't
remembering masking anything other than your personal password). I don't think 
the
shell script ever receives or deals with the values so the only next candidate 
would
be the native C code.

Can you try escaping characters when storing them and see if you have any luck? 
Are
you able to change your own password if only to try and identify the problem?

I'm using an invalid group password just to confirm that the connection gets 
farther
(it does). When I use the valid group password (the one with special 
characters) it
just hangs. So I suspected that the special characters was the issue.

I tried from the GUI adding backslashes before the special characters, but that
didn't work either.

Hi,
I can successfully connect to my company's VPN even with an @-sign in the 
username,
the userid is in the form <first name>.<last name>@<country>.<company>.com 
I don't have any special characters in the secret or the password.

Hi,
I want to connect to a cisco Ip-sec VPN, but I can´t get a connection. My 
username contains an @ (XXXXX@YYYYY). How can I find out if its the @ in the 
username that causes the connection failure?

[deleted comment]

I've found a solution to the problem of no "@" in the username. 


Same problem is on fedora13, but if you compile vpnc from the svn, usernames 
with @ in them started working with the same config as before!

Here is the comparision of two compiles:
compiled from svn trunk on fc13:
/usr/local/vpnc/sbin/vpnc --version
vpnc version 0.5.3-449
Copyright (C) 2002-2006 Geoffrey Keating, Maurice Massar, others
vpnc comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of vpnc under the terms of the GNU General
Public License.  For more information about these matters, see the files
named COPYING.
Built with certificate support.

Supported DH-Groups: nopfs dh1 dh2 dh5
Supported Hash-Methods: md5 sha1
Supported Encryptions: null des 3des aes128 aes192 aes256
Supported Auth-Methods: psk psk+xauth hybrid(rsa)

Compiled on android (same features as on fedora13 nonsvn):
Built without openssl (certificate) support.

Supported DH-Groups: nopfs dh1 dh2 dh5
Supported Hash-Methods: md5 sha1
Supported Encryptions: null des 3des aes128 aes192 aes256
Supported Auth-Methods: psk psk+xauth


So basically bug is solved in vpnc latest svn, could someone merge it into 
"get-a-robot-vpnc"? 

Thanks in advance.