Hello there,
got some strange behaviour with pluto. Here's what i am trying to do:
I wanted to connect a Box running Debian Etch[call it "remote"] to my
Debian Sarge[lets call that "local"].
The remote side is:
* using Openswan 2.4.4
* using kernel 2.6.16.13 with netkey
* natted
My local side is:
* using Openswan 2.2.0
* using kernel 2.6.14.6 with grsec-Additions(http://www.grsecurity.net)
and Netkey.
* not natted
So, here is the local connection definition:
conn conntest
left=%any
leftsubnet=vhost:%no,%priv
right=%defaultroute
rightsubnet=192.168.0.0/24
rightid=@my.id
authby=secret
type=tunnel
keyingtries=3
auto=add
Sorry, but i am currently unable to reach the remote side. Now this
happens if the remote side tries to initiate a connection:
from /var/log/auth.log:
pluto[20056]: "conntest"[1] $remote_public_ip #1: transition from state (null) to state STATE_MAIN_R1
pluto[20056]: "conntest"[1] $remote_public_ip #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
pluto[20056]: "conntest"[1] $remote_public_ip #1: WARNING: compute_dh_shared(): for OAKLEY_GROUP_MODP1536 took 220392 usec
pluto[20056]: "conntest"[1] $remote_public_ip #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
pluto[20056]: "conntest"[1] $remote_public_ip #1: Peer ID is ID_IPV4_ADDR: '192.168.0.227'
pluto[20056]: "conntest"[2] $remote_public_ip #1: deleting connection "conntest" instance with peer $remote_public_ip {isakmp=#0/ipsec=#0}
pluto[20056]: "conntest"[2] $remote_public_ip #1: I did not send a certificate because I do not have one.
pluto[20056]: "conntest"[2] $remote_public_ip #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
pluto[20056]: | NAT-T: new mapping $remote_public_ip:500/4500)
pluto[20056]: "conntest"[2] $remote_public_ip:4500 #1: sent MR3, ISAKMP SA established
pluto[20056]: "conntest"[2] $remote_public_ip:4500 #2: responding to Quick Mode
pluto[20056]: "conntest"[2] $remote_public_ip:4500 #2: WARNING: compute_dh_shared(): for OAKLEY_GROUP_MODP1536 took 206820 usec
pluto[20056]: "conntest"[2] $remote_public_ip:4500 #2: ASSERTION FAILED at kernel.c:2037: st->st_esp.keymat_len == (key_len + ei->authkeylen)
from syslog:
kernel: grsec: From $local_ip: signal 11 sent to /usr/lib/ipsec/pluto[pluto:20056] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/ipsec/_plutorun[_plutorun:26364] uid/euid:0/0 gid/egid:0/0
kernel: grsec: From $local_ip: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/lib/ipsec/pluto[pluto:20056] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/ipsec/_plutorun[_plutorun:26364] uid/euid:0/0 gid/egid:0/0
ipsec__plutorun: /usr/lib/ipsec/_plutorun: line 1: 20056 Segmentation fault /usr/lib/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --uniqueids --nat_traversal --virtual_private %v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.24.0/24
ipsec__plutorun: !pluto failure!: exited with error status 139 (signal 11)
So, after this lengthy description: Apparently pluto in Openswan 2.2.0
doesn't like natted clients using Openswan 2.4.4, I got two tunnels to
Openswan 2.4.4 without NAT working fine. What I'd like to know:
* Are there any known incompabilities to the grsecurity-Kernel-patch?
Would it make sense to try again without it?
* Are there known issues when connecting different versions of
openswan?
* Anything i could do to dignose this problem any further? Or should I
just update Openswan and try again?
thanks in Advance...
Stefan
--
Das Vertrauen gibt dem Gespraech mehr Stoff als Geist.
François Duc de La Rochefoucauld
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20060509/ebb44d31/attachment.bin