[Openswan Users] WG: Problems connecting to IPSec server

[Martin Krellmann]

Okay...
- I changed to leftprotoport=17/1701.
- Don't know if a hardware rng is present... I installed rng-tools, but
don't found rngd to start the service.
- I've disabled send and accept redirects by adding a little script to
/etc/init.d/rc.local
- Yes there is only one switch between client and server
- I think all certs are from the same CA... I set the ipsec up after a
reinstallation of the system, so I had to configure a new CA an regenerated
all certificates. I've even generated a new client certificate.

The Oakley.log tells me that there is somewhere a private key missing, but I
can't get where.
Does both sides need all keys?
(The cacert that was uses for signing the other certs, is the one installed
in ipsec - I checked it so that we can be sure)

Oakley.log is attached (the other one is in a extreme weired format ;) )

Greetings
Martin.

BTW: The typo is nice, I don't even saw it till now ;)


-----Ursprüngliche Nachricht-----
Von: Jacco de Leeuw [mailto:jacco2 at dds.nl] 
Gesendet: Samstag, 22. September 2007 01:21
An: Openswan Users
Betreff: Re: [Openswan Users] WG: Problems connecting to IPSec server

Martin Krellmann wrote:

> leftprotoport=17/%any

I'd say: use leftprotoport=17/1701 and phase out non-updated clients.

> Hardware RNG detected, testing if used properly                 [FAILED]
>   Hardware RNG is present but 'rngd' is not running.

Does your CPU have a hardware RNG on board?

>   No harware random used!

Cool, you found a typo in Openswan :-)

> NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]
>   Please disable /proc/sys/net/ipv4/conf/*/send_redirects
>   or NETKEY will cause the sending of bogus ICMP redirects!
> NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]
>   Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
>   or NETKEY will accept bogus ICMP redirects!

Better follow this advice.

> NAT is not involved in the test environment (i'm trying to connect on LAN
to
> the server), but later it'll be necessary because the server is behind a
> firewall/router

No gear between the client and the server, except perhaps a switch or
a hub?

> decrypting 56 bytes using algorithm OAKLEY_3DES_CBC
> byte 2 of ISAKMP Hash Payload must be zero, but is not
> malformed payload in packet

Are all certificates generated by the same CA? Did you regenerate
your CA and used an old cert from the previous CA, perhaps?

> Vpn-log.html contains the output of the windows diagnostic log for the vpn
> connection attempt. Maybe this is useful, too.

It's in a weird format, Doesn't ring a bell with me. The Oakley.log might
be more interesting.

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oakley.log
Type: application/octet-stream
Size: 88331 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20070923/b7a9424a/attachment-0001.obj