[Openswan Users] WLAN IPsec implementation

Zach zach at zerobit.net
Sun May 15 14:41:26 CEST 2005


	Oddly enough it looks like when I specify the right side of the
connection with anything other than %any I get the ubiquitous "No connection
is known for..." error message. Also having the leftsubnet=0.0.0.0/0
specified in the connection does this, even with right=%any. I'm not sure
why, earlier in the logs it see the IKE packets coming from what's specified
in "right=". 
	I also noticed you don't have Openswan setup to tunnel l2tp, I
considered this option as well, but it appears the ipsec.exe only works with
x509 certs (I've since switched from certs to PSK auth, with the same
results). Mind me asking what you use?

------------------------------------------------
PGP public key:
http://www.zerobit.net/zach.asc
 
KeyID:
0x98DEBD82 
 

-----Original Message-----
From: Bryan McAninch [mailto:bryan at mcaninch.org] 
Sent: Saturday, May 14, 2005 10:35 PM
To: 'Zach'
Cc: users at openswan.org
Subject: RE: [Openswan Users] WLAN IPsec implementation


Zach,

I would recommend using a PSK instead of x.509, as I've encountered problems
during Phase 1 with XP/x.509 - namely "Hash Payload has an unknown value".
Also, XP (as well 2k) supports PFS, so use it if you can.

My laptop's IP is 192.168.69.4/24, default route is 192.168.69.1
eth4 of my Linux FW/VPN is connected to my WAP via x-over cable - its IP is
192.168.69.1/24, default route is ISP gateway. I am currently running
Slackware 10.1 with OpenSWAN 2.3.1 on a 2.4.30 kernel.

The config on the FW/VPN looks something like this:

config setup
        interfaces="%defaultroute ipsec1=eth4"
        klipsdebug=none
        plutodebug=none
        plutowait=no

conn %default
        auto=start
        compress=yes
        left=%defaultroute

conn laptop
        auto=add
	  authby=secret
        rekey=no
        left=192.168.69.1
        leftsubnet=0.0.0.0/0
        right=192.168.69.4

The windows configuration would take several paragraphs to detail, please
contact me off the list if you need further assistance.

As you can see, the above configuration allows my laptop to access anything
(leftsubnet=0.0.0.0/0), assuming it's permitted by the firewall policy, via
the IPSec over 802.11 connection. I also use the 'rekey=no' option with
Windows client since without it, I get numerous amounts of overlapping Phase
1 & 2 SA's (which consumes valuable resources on the 400MHz/128M FW/VPN).

Bryan

-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Zach
Sent: Saturday, May 14, 2005 4:14 PM
To: 'Zach'; 'Jacco de Leeuw'; users at openswan.org; 'Paul Wouters'
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
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl


_______________________________________________
Users mailing list
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users





More information about the Users mailing list