[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    [strongSwan] Re: INVALID_MESSAGE_IDs (duplicate) from Checkpoint NG
From:       smcdermott () questra ! com (Scott Mcdermott)
Date:       2005-03-11 5:25:27
Message-ID: 20050311042549.GD960 () questra ! com
[Download RAW message or body]

To users@lists.strongswan.org on Thu 10/03 04:45 -0800:
> I am now having a new problem with a Checkpoint FW-1
> partner, where the old Racoon system worked fine before.
> My partner tells me the exact version is listed as
> "Checkpoint NG With Application Intelligence (R54) build
> 289."
> 
> I believe the ISAKMP SA is established fine, but Phase 2 is
> where we are going wrong.  Over and over again in the logs I
> get the following message (sanitized slightly):
> 
> [...]
> 
> > state object #17 found, in STATE_MAIN_R3
> "remote-lan" #17: Quick Mode I1 message is unacceptable because it uses a \
> previously used Message ID 0x6f2448f8 (perhaps this is a duplicated packet) \
> "remote-lan" #17: sending encrypted notification INVALID_MESSAGE_ID to 1.2.3.4:500

I think the message above is only occuring because of
previous errors which I didn't notice.  On closer inspection
I found this:

"remote-lan" #238: cannot respond to IPsec SA request because no connection is known \
for 10.30.4.20/32===<mygateway>...<remotegateway>===192.168.31.76/32 "remote-lan" \
#238: sending encrypted notification INVALID_ID_INFORMATION to <remotegateway>:500

My leftsubnet is 10.30.4.0/22 and the rightsubnet is
192.168.31.0/24 on the remote end.  Looks like the remote is
trying to establish a tunnel with /32s on both ends, i.e. is
trying to make a tunnel for every source/IP pair within the
designated network, instead of using the actual specified
/22 and /24 networks.

After doing some fishing on this I read several posts that
Checkpoint does indeed have this peculiar behavior, and
that others have encountered interoperability problems with
*swan because of it, but I couldn't figure out if there was
some way to override or fix it, and no solutions seemed to
be posted in mailing list archives.  It's not likely I can
get the remote end to fix this problem; they are pointing to
the fact that it worked before with my old Racoon software
and it's therefore my problem, even though it seems to me
that it's clearly broken behavior (it should just establish
a single tunnel with the specified encryption domains
instead of "decaying" it into individual /32s on each
connection).

Is there a way to override Strongswan and allow the tunnel
to be established not in the case of an EXACT match, but if
both ends are WITHIN the leftsubnet and rightsubnet? I
found a "rightsubnetwithin" by grepping through the source
(it's not documented in ipsec.conf man page) but this seems
to be intended for Road Warrior style connections...I tried
it anyways and it does not work.

Any ideas?


[prev in list] [next in list] [prev in thread] [next in thread]