[Openswan Users]
ASSERTION FAILED at crypto.c:219: st->st_new_iv_len >=
e->enc_blocksize
Paul Wouters
paul at xelerance.com
Sun May 15 12:55:02 CEST 2005
On Sat, 14 May 2005, Zach wrote:
Michael was working on this issue but had problems reproducing this problem.
Michael, try plutodebug=all, or talk to Zach about reproducing this bug.
Paul
> Date: Sat, 14 May 2005 16:14:21 -0500
> From: Zach <zach at zerobit.net>
> To: 'Zach' <zach at zerobit.net>, 'Jacco de Leeuw' <jacco2 at dds.nl>,
> users at openswan.org, 'Paul Wouters' <paul at xelerance.com>
> Subject: RE: [Openswan Users] WLAN IPsec implementation
>
> Did a little more testing myself and found out that with plutodebug=all in
> 2.3.1 I get:
>
> cat /var/log/auth.log | grep -i "assertion"
> May 13 10:51:08 localhost pluto[13383]: "wireless"[2] 192.168.2.2 #3:
> ASSERTION FAILED at crypto.c:219: st->st_new_iv_len >= e->enc_blocksize
>
>
>
> In 2.3.0 with plutodebug=none I get similar results to the same in 2.3.1
> ("established" security association that just gets inexplicably deleted).
> Again with 2.3.0 plutodebug=all I get an assertion failed. However in a
> different .c file.
>
> cat /var/log/auth.log | grep -i "assertion"
> May 14 16:01:53 localhost pluto[2944]: "wireless"[1] 192.168.2.3 #2:
> ASSERTION FAILED at demux.c:1799: STATE_IKE_FLOOR <= from_state &&
> from_state <= STATE_IKE_ROOF
>
> I've since turned x509 cert auth off, opting for PSK instead to reduce some
> complexity in my configuration. Anyone have any ideas what this could be?
> I'm assuming it's something on my machine and not the code, but I haven't a
> clue beyond that assumption.
>
> ------------------------------------------------
> PGP public key:
> http://www.zerobit.net/zach.asc
>
> KeyID:
> 0x98DEBD82
>
> -----Original Message-----
> From: Zach [mailto:zach at zerobit.net]
> Sent: Friday, May 13, 2005 11:28 AM
> To: 'Jacco de Leeuw'; users at openswan.org; 'Paul Wouters'
> Cc: zach at zerobit.net
> Subject: RE: [Openswan Users] WLAN IPsec implementation
>
> Jacco, Paul thanks for the responses. Here's a diagram (a rather bad one, my
> ASCII skills are lacking =D ) of the network.
>
> /-Eth1(192.168.2.1/24)---Access Point*---Notebook(.2)
> Ubuntu
> \-Eth0---|
> |
> |-Wired LAN---Router-----Internet
>
> *Eth1 plugged into LAN side of access point.
>
> I tried implementing some of you all's suggestions, like taking out the
> leftsubnet= statement, which was in there cause this config was copied over
> from another Openswan setup I've got that would only work with it set like
> that, dunno why. I also removed virtual_private=, and nat_traversal=. I've
> managed to get a seg fault in 2.3.1 I'll paste it below.
>
> May 13 10:51:08 localhost pluto[13383]: "wireless"[2] 192.168.2.2 #3:
> ASSERTION FAILED at crypto.c:219: st->st_new_iv_len >= e->enc_blocksize
>
> So I went back to 2.3.0 - and killed detailed logging. Here's what I've got
> now.
>
> May 13 11:11:06 localhost pluto[19937]: "wireless"[1] 192.168.2.2 #1:
> responding to Main Mode from unknown peer 192.168.2.2
> May 13 11:11:06 localhost pluto[19937]: "wireless"[1] 192.168.2.2 #1:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> May 13 11:11:06 localhost pluto[19937]: "wireless"[1] 192.168.2.2 #1:
> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> May 13 11:11:06 localhost pluto[19937]: "wireless"[1] 192.168.2.2 #1: Main
> mode peer ID is ID_DER_ASN1_DN: 'C=US, ST=TX, L=Dallas, O=Athena, OU=VPN,
> CN=zach, E=zach at zerobit.net'
> May 13 11:11:06 localhost pluto[19937]: "wireless"[1] 192.168.2.2 #1: no crl
> from issuer "C=US, ST=TX, L=Dallas, O=Athena, OU=CA, CN=root,
> E=root at athena.zerobit.net" found (strict=no)
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #1:
> deleting connection "wireless" instance with peer 192.168.2.2
> {isakmp=#0/ipsec=#0}
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #1: I am
> sending my cert
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #1:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #1: sent
> MR3, ISAKMP SA established
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2:
> responding to Quick Mode
> May 13 11:11:06 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2:
> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2:
> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2: IPsec
> SA established {ESP=>0x4d2ac50c <0x3c495da2}
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #1:
> received Delete SA payload: deleting ISAKMP State #1
> May 13 11:11:07 localhost pluto[19937]: packet from 192.168.2.2:500:
> received and ignored informational message
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2: next
> payload type of ISAKMP Hash Payload has an unknown value: 159
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2:
> malformed payload in packet
> May 13 11:11:07 localhost pluto[19937]: "wireless"[2] 192.168.2.2 #2:
> sending notification PAYLOAD_MALFORMED to 192.168.2.2:500
>
> Seems as though the SA's being established, but something happens to kill
> it?
>
> Here's what my config file looks like after the changes.
>
> # /etc/ipsec.conf - Openswan IPsec configuration file
> # RCSID $Id: ipsec.conf.in,v 1.13 2004/03/24 04:14:39 ken Exp $
>
> # This file: /usr/share/doc/openswan/ipsec.conf-sample
> #
> # Manual: ipsec.conf.5
>
> version 2.0 # conforms to second version of ipsec.conf specification
>
> # basic configuration
> config setup
> # Debug-logging controls: "none" for (almost) none, "all" for lots.
> klipsdebug=none
> plutodebug=none
> # Add connections here
>
>
> # Left security gateway, subnet behind it, next hop toward right.
> conn %default
> left=192.168.2.1
> leftrsasigkey=%cert
> rightrsasigkey=%cert
> leftcert=host.cert.pem
>
>
> conn wireless
> leftprotoport=17/1701
> rightprotoport=17/1701
> pfs=no
> rekey=no
> right=%any
> auto=add
>
> #Disable Opportunistic Encryption
> include /etc/ipsec.d/examples/no_oe.conf
>
> Also, I have pfs=no cause I didn't think the XP client did Perfect Forward
> Security I'd love to use it But Mr. Gates said no =D. The rekey=no was
> added because of some problems I was having with Openswan re-keying (and
> subsequently killing the connection) with XP/2000 connections on my other
> Openswan implementation. It looks like with it off the XP client initiates a
> rekey every hour or so and stays connected. But this was a while ago and I
> can't remember what version of Openswan I was using.
>
> ------------------------------------------------
> PGP public key:
> http://www.zerobit.net/zach.asc
>
> KeyID:
> 0x98DEBD82
>
> -----Original Message-----
> From: Jacco de Leeuw [mailto:jacco2 at dds.nl]
> Sent: Friday, May 13, 2005 3:43 AM
> To: users at openswan.org
> Subject: Re: [Openswan Users] WLAN IPsec implementation
>
> Zach wrote:
>
>> Hello everyone, I'm having a difficult time setting up a VPN connection
>> between my XP2/SP2 notebook and Ubuntu box running Openswan 2.3.1
>> config setup
>>
>> # Debug-logging controls: "none" for (almost) none, "all" for lots.
>> klipsdebug=none
>> plutodebug=all
>
> Normally plutodebug=all is not needed. Most problems are simply due to
> a configuration error.
>
>> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
>
> You need to exclude your internal subnet here. Add this:
> ... ,%v4:!192.168.2.0/24
>
> Assuming that this is indeed your internal subnet. But I don't think this
> is the cause of the problem. You are probably not doing NAT on your WLAN,
> right?
>
>> conn %default
>> left=192.168.2.1
>> leftsubnet=192.168.2.1/32
>
> This leftsubnet= probably confuses the conn wireless.
> Could you remove it?
>
>> conn wireless
>> leftprotoport=17/1701
>> rightprotoport=17/1701
>> pfs=no
>> rekey=no
>> right=%any
>> rightsubnet=vhost:%no,%priv
>> auto=add
>
> rekey=no? Why is that?
>
>> conn conntointernet
>> leftsubnet=0.0.0.0/0
>> also=wireless
>
> This won't work with L2TP over IPsec. Once the packets are
> delivered to the L2TP daemon, Openswan is not involved anymore.
> So L2TP/PPP will have to do the forwarding to Internet.
>
> Could you decribe your setup with a diagram or something? Is your
> Ubuntu box behind a firewall? Remember, no L2TP daemon should be
> accessible from the Internet for obvious security reasons.
>
> Jacco
>
More information about the Users
mailing list