Andreas,
both users have the same "type" of DN, both with the same special
characters, only name and email are different.
Andreas Steffen wrote:
> You say that a connection with user1 can be set up. If the DN of
> the user1 contains special characters, too, then the coding of the
> DNs cannot be the reason that connection user2 is not found.
> Could you comment on this?
>
> Regards
>
> Andreas
>
> P.S. I planned the release of 0.9.12 to coincide with freeswan-1.98
> (i.e. end of May or beginning of June) but I might code it earlier
> if it is really your problem.
>>we do have a "@" and a "-" and also numbers in the DN - we use an email
>>address in there.
>>Do you have any idea when 0.9.12 will be out so I can try it? :-)
>>
>>TIA, Harry
>>
>>Andreas Steffen wrote:
>>
>>
>>>With roadwarrior connections it is normal that first a tentative
>>>connection is chosen quite arbitrarily (in your case the connection
>>>"user1"). When the peer ID is transmitted Pluto then looks for
>>>a connection matching the ID. Does the connection definition
>>>for user2 exist when you type "ipsec auto --status" and does
>>>the ID match '<user 2's CN>'. If yes, does your distinguished
>>>name contain some special characters like e.g. '@' or '&'?
>>>It might be that the ASN.1 coding of the two strings differs
>>>although they print image is the same. Version 0.9.12 of the X.509
>>>patch will be more lenient in the type checking. So as a
>>>workaround avoid special characters in the CN.
>>>
>>>>here are the logfile messages when my user #2 tries to connect:
>>>>
>>>>Apr 30 17:08:21 localhost Pluto[14643]: packet from 149.228.54.32:500:
>>>>ignoring Vendor ID payload
>>>>Apr 30 17:08:21 localhost Pluto[14643]: "user1" 149.228.54.32 #4:
>>>>responding to Main Mode from unknown peer 149.228.54.32
>>>>Apr 30 17:08:23 localhost Pluto[14643]: "hb-net1" 149.228.54.32 #4:
>>>>ignoring Vendor ID payload
>>>>Apr 30 17:08:23 localhost last message repeated 2 times
>>>>Apr 30 17:08:25 localhost Pluto[14643]: "user1" 149.228.54.32 #4:
>>>>ignoring informational payload, type IPSEC_INITIAL_CONTACT
>>>>Apr 30 17:08:25 localhost Pluto[14643]: "user1" 149.228.54.32 #4: Peer
>>>>ID is ID_DER_ASN1_DN: '<user 2's CN>'
>>>>Apr 30 17:08:25 localhost Pluto[14643]: "user1" 149.228.54.32 #4: no
>>>>suitable connection for peer '<user 2's CN>'
>>>>[...repeating from message IPSEC_INITIAL_CONTACT several times...]
>>>>
>>>>Somehow it seems Pluto always tries to use the first conn entry it finds
>>>>and does not take the CN of the connecting user into account for finding
>>>>a matching connection. :-/
>>>>
>>>>What could be wrong here?
>>>>
>>>>TIA, Harry
>>>>
>>>>Andreas Steffen wrote:
>>>>
>>>>
>>>>
>>>>>you've got the idea right! I wonder why your configuration fails.
>>>>>Could you post a log detailing the error?
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>I have a question regarding the setup for different users with FreeS/WAN.
>>>>>>
>>>>>>I have a working VPN with SafeNet and FreeS/WAN which is fine as long as
>>>>>>I have one user connected as a road warrior. The problem I have comes up
>>>>>>when I wan to add another user with his own certificate.
>>>>>>
>>>>>>I want to have a different cert for each user so in case somebody must
>>>>>>be forced out of the network I can simply remove his config lines.
>>>>>>
>>>>>>My ipsec.conf looks like this:
>>>>>>
>>>>>>config setup
>>>>>> interfaces=%defaultroute
>>>>>> klipsdebug=none
>>>>>> plutodebug=none
>>>>>> plutoload=%search
>>>>>> plutostart=%search
>>>>>> uniqueids=yes
>>>>>>
>>>>>>conn %default
>>>>>> authby=rsasig
>>>>>> auto=add
>>>>>> compress=yes
>>>>>> disablearrivalcheck=no
>>>>>> keyingtries=1
>>>>>> left=%defaultroute
>>>>>> leftcert=vpn.pem
>>>>>> leftfirewall=yes
>>>>>> leftrsasigkey=%cert
>>>>>> pfs=yes
>>>>>> right=%any
>>>>>> rightrsasigkey=%cert
>>>>>>
>>>>>>conn user1
>>>>>> leftsubnet=192.168.100.0/24
>>>>>> rightid="<user 1's CN>"
>>>>>>
>>>>>>conn user2
>>>>>> leftsubnet=192.168.100.0/24
>>>>>> rightid="<user 2's CN>"
>>>>>>
>>>>>>With only 1 user in the file it works fine - as soon as I add the second
>>>>>>it fails. :-/
>>>>>>
>>>>>>Is there a way to get the basic idea working somehow or have I some
>>>>>>missunderstanding somewhere.
>>>>>>I would not like to have a solution where I have to renew certificates
>>>>>>for alot of people just because I want to restrict one users access.
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:57 CEST