IPv6 readyNote: This archive passes through spamassassin. Every mail marked with the subject "*****SPAM*****" has exceed a certain threshold of spam-like behaviour.

Re: [Users] Several users configuration

From: Harry Brueckner (harry.brueckner_at_orange-digital.de)
Date: Mon May 06 2002 - 13:35:06 CEST


Andreas,

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