Hello Ermal, On Tues., Feb. 12, 2013, Ermal Luçi wrote: >On Fri, Feb 8, 2013 at 4:01 PM, [email protected] wrote: >> Other IPSec clients like pluto(8) constrain the possible XAUTH >> usernames to either contain a @ (at-character) or when using >> certificates (as in the case of RSA+XAUTH) forcibly overwrite >> the XAUTH username with the certificate's CN which is nearly >> always more than 16 characters in length. Examples follow: >> >> XAUTH usernames PFSense error >> --------------- ------------- >> [email protected] Invalid character '@' >> [email protected] Invalid character '@' and > 16 long >> normal.hostname.com Over 16 characters long >> >> None of these XAUTH usernames are invalid according to >> the IETF specification, but PFSense rejects them all. >> >> XAUTH WORKAROUND >> >> Hack the user database: >> >> 1. Log into the web configuration interface >> 2. Add a plain looking username like 'myhost' >> 3. Give it a password, no need for a shared key >> 4. Make sure it has 'User - VPN - IPSec xauth Dialin' privelege >> 5. Log out of the web configuration interface >> >> A. Log into the TTY somehow, using SSH or the serial interface >> B. Type '/etc/rc.conf_mount_rw' to mount filesystems writable >> C. Type 'viconfig' to edit the PHP-based web configuration >> D. Search (type slash /) for your newly added user near <user> >> E. Change it to whatever you require, with '@' or over 16 chars >> F. Save the document and quit (type 'Z' twice or ':wq') >> >> Coffee break. >> >> G. Type 'vipw' to edit the user password file >> H. Change the user name here as well to match step E >> I. For good measure type 'passwd <newusername>' with the pw >> J. Log out of the TTY >> >> After reboots or password database rebuilds (maybe more) you will >> see error messages in the main system log relating to the new >> 'invalid' user names. It seems that the hacky new invalid user >> names don't cause any real problems however. >> >> BUG? >> >> Does this XAUTH limitation qualify as a bug or >> improvement feature request? >> >> QUESTIONS >> >> In case anybody knows that this kind of hacking will >> lead to certain problems, please share your knowlege. >> >> Or if this XAUTH problem is better solved in a different way, >> that would be good to know as well, thanks. >> >Which version you are doing test with 2.1, 2.0.x? > I tested with both 2.0.1 and 2.1-BETA1_i386_20130110. The only difference between the two is that the 2.1 built applications like vipw(1) completely fail and reject invalid user names which make it necessary to vi /etc/passwd rather than vipw(1). Then reboot (I guess) to recreate the pw databasees. The 2.0.x versions of vipw(1) and other programs that read passwd(4) don't fail.
Whatever, this is all quite hacky from the start. It sure would be great if the developers of the system interface to racoon would use a appropriate user database rather than the inappropriate DES-based crypt(3) passwd(4) file. That one is useless for almost any XAUTH username. Regards, Michael _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
