[Openswan Users] openswan + freeswan config

Fri Apr 17 10:00:11 EDT 2009

thank for the response Paul & Curu. I agree they are both old versions but
that's what Novell Suse officially supports on their distribution 8 & 10 so
to say (will update management :) )...I was able to get the IPSEC working in
my lab environment between Suse 8 and Suse 10 with the exact same config as
described below without firewall and natting/patting.

here is some more debugging...maybe it can benefit someone else.

*//from SYSTEM1 authlog*
//system1 is getting ready to send a packet to system2
Apr 16 14:51:29 system1 pluto[21904]: "system1-system2" #162: initiating
Main Mode
Apr 16 14:51:29 system1 pluto[21904]: | **emit ISAKMP Message:
Apr 16 14:51:29 system1 pluto[21904]: |    initiator cookie:
Apr 16 14:51:29 system1 pluto[21904]: |   2b 06 b2 30  c6 f3 5b c8  „³
system1 cookie id
Apr 16 14:51:29 system1 pluto[21904]: |    responder cookie:
Apr 16 14:51:29 system1 pluto[21904]: |   00 00 00 00  00 00 00 00

*//from system2 pluto.log*
received 176 bytes from 142.***.208.44:500 on bond0 (port=500)
|   2b 06 b2 30  c6 f3 5b c8  00 00 00 00  00 00 00 00
|   01 10 02 00  00 00 00 00  00 00 00 b0  00 00 00 94
|   00 00 00 01  00 00 00 01  00 00 00 88  00 01 00 04
|   03 00 00 20  00 01 00 00  80 0b 00 01  80 0c 0e 10
|   80 01 00 05  80 02 00 02  80 03 00 03  80 04 00 05
|   03 00 00 20  01 01 00 00  80 0b 00 01  80 0c 0e 10
|   80 01 00 05  80 02 00 01  80 03 00 03  80 04 00 05
|   03 00 00 20  02 01 00 00  80 0b 00 01  80 0c 0e 10
|   80 01 00 05  80 02 00 02  80 03 00 03  80 04 00 02
|   00 00 00 20  03 01 00 00  80 0b 00 01  80 0c 0e 10
|   80 01 00 05  80 02 00 01  80 03 00 03  80 04 00 02
| **parse ISAKMP Message:
*|    initiator cookie:
|   2b 06 b2 30  c6 f3 5b c8 --> system1 cookie ID
|    responder cookie:
|   00 00 00 00  00 00 00 00 *
|    next payload type: ISAKMP_NEXT_SA
|    ISAKMP version: ISAKMP Version 1.0
|    exchange type: ISAKMP_XCHG_IDPROT
|    flags: none
|    message ID:  00 00 00 00
|    length: 176
.
.
.
| processing connection system1-system2
|* ICOOKIE:  2b 06 b2 30  c6 f3 5b c8
| RCOOKIE:  48 e0 ec 0a  97 1e ce ef  --> ipsec on system2 inserting its own
cookie ID *
| peer:  8e cd d0 2c
| state hash entry 16
.
.
.
| sending reply packet to 142.***.208.44:500 (from port=500)  //system2 is
sending packet to system1
| sending 116 bytes for STATE_MAIN_R0 through bond0:500 to
142.***.208.44:500:
|   *2b 06 b2 30  c6 f3 5b c8*  48 e0 ec 0a  97 1e ce ef
|   01 10 02 00  00 00 00 00  00 00 00 74  0d 00 00 34
|   00 00 00 01  00 00 00 01  00 00 00 28  00 01 00 01
|   00 00 00 20  00 01 00 00  80 0b 00 01  80 0c 0e 10
|   80 01 00 05  80 02 00 02  80 03 00 03  80 04 00 05
|   0d 00 00 10  4f 45 7a 7d  46 46 46 66  67 72 5f 65
|   00 00 00 14  af ca d7 13  68 a1 f1 c9  6b 86 96 fc
|   77 57 01 00

system1 doesn't see this reply packet; it is possible it could be network
problem but look at the following tcpdump from ssytem1 it shows  its getting
packets from system2

system1:~ # tcpdump -v -i eth0 host 49.***.29.12[system2 ip]
tcpdump: listening on eth0
14:10:58.926246 system1.ike > system2.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 37135, len 204)
14:10:58.928111 system2 > system1: icmp: system2 udp port ike unreachable
[tos 0xc0]  (ttl 64, id 27863, len 232) *--> ipsec was down on
system2*(icmp is blocked by firewall)
14:11:06.528892 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 0, len 240) *--> system1 didnt respond since i
didnt see this come in*
14:11:08.597133 system1.ike > system2.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 37404, len 204) *--> Initial packet from
system1*
14:11:08.598345 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 R
ident: [|sa] (DF) (ttl 64, id 0, len 144)* --> response back from
system2** (now
why is ipsec not responding back to this, the Response packet is actually
getting to system1 ) *
14:11:16.597915 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 0, len 240) --> *response back from system2
??? 2nd packet*
14:11:18.597854 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 R
ident: [|sa] (DF) (ttl 64, id 0, len 144)
14:11:28.742482 system1.ike > system2.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 37696, len 204)
14:11:28.744684 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 R
ident: [|sa] (DF) (ttl 64, id 0, len 144)
14:11:36.745618 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 I
ident: [|sa] (DF) (ttl 64, id 0, len 240)
14:11:38.745504 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 R
ident: [|sa] (DF) (ttl 64, id 0, len 144)
14:11:38.745599 system2.ike > system1.ike: isakmp 1.0 msgid : phase 1 R
ident: [|sa] (DF) (ttl 64, id 0, len 144)

thanks
aasim

On Thu, Apr 16, 2009 at 10:31 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Wed, 15 Apr 2009, Aasim Ajaz wrote:
>
>  I am trying to create IPSEC tunnel between two linux system Suse 8 running
>> freeswan 1.98  & Suse 10 running
>> openswan 2.4 and so far no success. I have verified network setting few
>> times and they all look good.
>>
>
> Those versions are VERY ancient. All bets are off, and you have known DoS
> attacks that are possible against those systems. Plus many bugsfixes
> you are missing from the last 5+ years.
>
>  this is traffic flow from right to left side...
>> 86: 23:38:48.479208 49.***.29.12.500 > 142.***.208.44.500: udp 212
>>
>
> There is no point loggin udp packets. The first thing IPsec does is
> initiate crypto.
>
>  System2:~ # rpm -qa | grep openswan
>> openswan-2.4.4-18.9
>>
>
> Should upgrade to 2.4.14 really.
>
>  System2:~ # rpm -qa | grep ipsec
>> ipsec-tools-0.6.5-10.10
>>
>
> which does not ipsec-tools
>
> your config looks fine.
>
>  system02:~ # ipsec auto --verbose --up system1-system2
>> 002 "system01-system02" #3: initiating Main Mode
>> 104 "system01-system02" #3: STATE_MAIN_I1: initiate
>> 010 "system01-system02" #3: STATE_MAIN_I1: retransmission; will wait 20s
>> for response
>> 010 "system01-system02" #3: STATE_MAIN_I1: retransmission; will wait 20s
>> for response
>> 010 "system01-system02" #3: STATE_MAIN_I1: retransmission; will wait 40s
>> for response
>>
>
> You are not getting an answer to your first packet. This usually means
> a firewall is blocking things somewhere.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090417/7e2baf5d/attachment.html 