[Openswan Users] checkpoint->openS/WAN tries to initiate /32 IPsec SA for every NEW connection

[Albert Siersema]

Hello all,

To clear up and eleborate on my previous post, I discovered that the 
checkpoint firewall tries to setup seperate IPsec SAs for every single
host (/32) that initiates a new connection (NEW from a stateful firewall
state machine perspective, e.g. ICMP ping echo request, TCP with SYN, etc.)
Connections from openswan to checkpoint and corresponding reply traffic
are tunneled without any problems.

I know this probably is a checkpoint issue, but since I couldn't get
any answers from checkpoint knowhowwies (or googling or interop docs)
and there's after all an IPsec crowd on this list i was hoping that someone 
can point me

Albert Siersema wrote:
> Hello peoples,
> 
> I'm trying to set up a network<->network (tunnel mode) tunnel with a 
> nokia checkpoint firewall. No problems with freeswan but after upgrading to
> openswan we're in trouble.
> 
> The network<->network tunnel (ISAKMP+IPsec SA) seems to be up&running 
> with this config:
> 
>         auth=esp
>         authby=secret
>         pfs=yes
>         leftsendcert=no
>         left=a.b.c.d
>         leftsubnet=10.0.0.0/255.255.0.0
>         right=e.f.g.h
>         rightsubnet=10.1.0.0/255.255.0.0
>         ikelifetime=480m
>         keylife=28800
>         type=tunnel
> 
> (yes i know, tunnel is the default type anyway and 480m == 28800 :-).
> At least, the log file states "IPsec SA established" (along with ISAKMP 
> SA of course) and i'm able to ping a host in the 10.1 network.
> 
> However, the log files keep mentioning:
> 
> cannot respond to IPsec SA request because no connection is known for
> 10.0.0.12/32===a.b.c.d[S-C]...e.f.g.h===10.1.9.100/32
> 
> sending encrypted notification INVALID_MESSAGE_ID to e.f.g.h:500
> Quick Mode I1 message is unacceptable because it uses a previously used 
> Message ID 0xaaaaaaaaa (perhaps this is a duplicated packet)
> 
> I was told the remote firewall is configured with NAT-T disabled and 
> matching configuration (otherwise the one IPsec SA wouldn't be 
> established in the first place).
> 
> Could anyone point me in the right direction where to look ?
> What does the [S-C] in the logs mean by the way ?
> See below for ipsec status
> 
> TIA,
> Albert
> 
> --------------
> 
> 000 interface ipsec0/eth1 a.b.c.d
> 000 %myid = (none)
> 000 debug none
> 000
> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, 
> keysizemin=168, keysizemax=168
> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, 
> keysizemin=128, keysizemax=256
> 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, 
> keysizemin=128, keysizemax=128
> 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, 
> keysizemin=160, keysizemax=160
> 000
> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, 
> keydeflen=128
> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, 
> keydeflen=192
> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA, hashsize=20
> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
> 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
> 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
> 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
> 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
> 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
> 000
> 000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,6,36} 
> trans={0,6,96} attrs={0,6,160}
> 000
> 000 "ME-THEM": 10.0.0.0/16===a.b.c.d[S-C]...e.f.g.h===10.1.0.0/16; 
> erouted; eroute owner: #14
> 000 "ME-THEM":   ike_life: 28800s; ipsec_life: 28800s; rekey_margin: 
> 540s; rekey_fuzz: 100%; keyingtries: 0
> 000 "ME-THEM":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 16,16; 
> interface: eth1;
> 000 "ME-THEM":   newest ISAKMP SA: #17; newest IPsec SA: #14;
> 000 "ME-THEM":   IKE algorithms wanted: 5_000-1-5, 5_000-1-2, 5_000-2-5, 
> 5_000-2-2, flags=-strict
> 000 "ME-THEM":   IKE algorithms found:  5_192-1_128-5, 5_192-1_128-2, 
> 5_192-2_160-5, 5_192-2_160-2,
> 000 "ME-THEM":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1024
> 000 "ME-THEM":   ESP algorithms wanted: 3_000-1, 3_000-2, flags=-strict
> 000 "ME-THEM":   ESP algorithms loaded: 3_000-1, 3_000-2, flags=-strict
> 000 "ME-THEM":   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=<Phase1>
> 000
> 000 #16: "ME-THEM" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> EVENT_SA_REPLACE in 28055s
> 000 #15: "ME-THEM" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> EVENT_SA_REPLACE in 27743s
> 000 #14: "ME-THEM" STATE_QUICK_I2 (sent QI2, IPsec SA established); 
> EVENT_SA_REPLACE in 26714s; newest IPSEC; eroute owner
> 000 #14: "ME-THEM" esp.cce2061d at e.f.g.h esp.76e85b42 at a.b.c.d 
> tun.1004 at e.f.g.h tun.1003 at a.b.c.d
> 000 #13: "ME-THEM" STATE_MAIN_I4 (ISAKMP SA established); 
> EVENT_SA_REPLACE in 26715s
> 000 #17: "ME-THEM" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> EVENT_SA_REPLACE in 28367s; newest ISAKMP
> 
> _______________________________________________
> Users mailing list
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users