[Openswan Users] Client not accepting proposals openswan receives fine

[ljane at xs4all.nl]

> On Tue, 14 Sep 2004 ljane at xs4all.nl wrote:
>
>> I tested it with a couple client wich are: thegreenbow 2.50, ssh
>> sentinel
>> 1.3.22 and 1.4 and Safenet/Softremote 9.2.1.
>> With all those clients i'm getting the same crap: client does not accept
>> proposal from server, server does accept proposal from client
>>
>> You will see below also a log file from softremote -> openswan 2.2.0dr4
>
> It seems from teh logs you show that softremote is trying xauth, which you
> don't seem to have enabled on openswan.
>
It just informs the server of his xauth capabilities, and also i did not
set any xauth setting so that would seem odd to me and besides he's making
the tunnel
>> I also tried to setup with strongswan 2.2.0 but it kept giving me the
>> same
>> crap :) also tried switching between algorithms e.g. 3des, aes128,
>> aes256
>> and several combinations with the hash algorithms, sha1 and md5 and
>> nothing, the problem still exists.
>
> Are there any options for either PFS and/or Aggressive vs Main mode? Try
> pfs=no just to see if the client likes that.
Tried that, did not work out :)
>
> I see a bunch of unknown vendor ids which could signal trouble, but I
> doubt all three software packages would have troubles
>
>> Sep 14 15:34:07 hallo pluto[7336]: "wtux-tux"[2] 192.168.128.21 #2:
>> IPsec
>> SA established {ESP=>0x2e29f531 <0x5d14e227}
>
> Note that you got an ipsec tunnel here!
Yes, i know that. but that's not the problem here.
>
>> Sep 14 15:35:02 hallo pluto[7336]: "wtux-tux"[2] 192.168.128.21 #3:
>> initiating Quick Mode RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS to replace #2
>> {using isakmp#1}
>> Sep 14 15:35:02 hallo pluto[7336]: "wtux-tux"[2] 192.168.128.21 #1:
>> ignoring informational payload, type NO_PROPOSAL_CHOSEN
>
> But here it gets killed. I think both sides are initiating and responding
> at the same time. Try changing auto=start to add=add on the openswan
> end.
As you already noticed you're self below it is on add ;)
>
>> ID is ID_DER_ASN1_DN: 'C=WL, ST=Wonder-State, L=Wonder-City, O=TUX,
>> OU=IPSEC Machines, CN=flappy.tux'
>
> I am not sure if it is a real bug, but I remember having had troubles with
> having OU= set. I always leave it blank now. (but it might be a prejudice)
> I would also not recommend the "-" sign in the certificate. Some odd
> characters can cause problems with the ASN.1 parser.
Could try that, but i doubt it because three clients respond the same, i
guess the problem lies at the server but the real question is where
>
>> + _________________________ proc/net/ipsec_eroute
>> + test -r /proc/net/ipsec_eroute
>> + sort -sg +3 /proc/net/ipsec_eroute
>>           0.0.0.0/0          -> 192.168.128.21/32  =>
>> tun0x1002 at 192.168.128.21
>
> You have one tunnel up. Someone sends all their traffic to you.
> I guess that would be 192.168.128.1?
192.168.128.21, yes it's my test client
>
>> 000 "wtux-tux": 0.0.0.0/0===192.168.128.1[C=WL, ST=Wonder-State,
>> L=Wonder-City, O=TUX, OU=IPSEC Machines, CN=hallo.tux]...%any; unrouted;
>
> There it is. Seems to work.
That's right
>
>> conn wtux-tux
>>    auto=add
>
> Oh, you already have =add
Jup
>
>>    left=192.168.128.1
>>    leftrsasigkey=%cert
>>    leftcert=public_server.pem
>>    leftsubnet=0.0.0.0/0.0.0.0
>>    right=%any
>>    rightrsasigkey=%cert
>>    rightca="C=WL, ST=Wonder-State, L=Wonder-City, O=TUX, OU=SSL, CN=TUX
>> Private Primary C
> ertification Authority"
>
> Seems fine.
Seems fine to me too.
>
>> + test -r /proc/ksyms
>> + test -r /proc/kallsyms
>> + echo 'broken (redhat/fedora) 2.6 kernel without kallsyms'
>> broken (redhat/fedora) 2.6 kernel without kallsyms
>
> This is a buglet on our end I think, you have no module support right?
>
> you have a tunnel up. So what is going wrong?
The problem is that client proposals gets accepted by openswan but
openswan proposals gets not accepted by all three clients, all with
different settings.
Just as the titel of this thread tells you :)
>
> Paul