[Openswan Users] WG: Problems connecting to IPSec server
martin at krellmann.net
Sun Sep 23 05:26:23 EDT 2007
- 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
- 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 ;) )
BTW: The typo is nice, I don't even saw it till now ;)
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:
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
> the server), but later it'll be necessary because the server is behind a
No gear between the client and the server, except perhaps a switch or
> 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 de Leeuw mailto:jacco2 at dds.nl
Zaandam, The Netherlands http://www.jacco2.dds.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 88331 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20070923/b7a9424a/attachment-0001.obj
More information about the Users