[Ipsec-tools-commits] [ ipsec-tools-Bugs-1385632 ] Issues after far end reboots

[SourceForge.net <no...@so...>]

Bugs item #1385632, was opened at 2005-12-19 17:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1385632&group_id=74601

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: tim wilson (twilson100)
Assigned to: Nobody/Anonymous (nobody)
Summary: Issues after far end reboots

Initial Comment:
Hello;

Our configuration is below. The problem I'm seeing is:
 - 2 ends in transport mode are communicating fine
 - The far end reboots
 - The far end recovers and the ISAKMP SA is
(re)established
 - The IPSec SA's are (re)established
 - PROBLEM: the traffic to the far end is not received
by the near end application process, however the near
end's traffic is being received by the far end.
Ethereal indicates that ESP packets are being sent in
both directions (though, of course, I cannot see the
contents). After many timeouts, the near end usually
eventually fails with an error (from select() ) of
ESHUTDOWN (108) - /* cannot send after transport
endpoint shutdown*/

 - As a sanity test, if the send/receive applications
on either end are repeatedly started and stopped
without encryption they operate fine.
 - I compiled in/enabled DPD, and that cleared up an
invalid cookie situation I was seeing via Ethereal.
 - I attempted to make the server end passive (passive
on; generate_policy on) but that made no difference
(and I don't want to use generate_policy on this server
anyway).
 - Racoon continues to rotate ISAKMP and IPSec SA keys
normally, but the comm problem persists.
 - Once in a while the comm between the 2 ends recovers
properly, but that's very rare.
 - I don't know whether it's a configuration problem or
some other problem.

CONFIGURATION: 
  We are only encrypting SCTP traffic. Each end applies
the policies to any sctp traffic going to/from a large
range of ip addresses, while the racoon config only
specifies "anonymous". The configuration files below
are used in both ends (though one end is a client and
the other is a server talking to multiple clients).

setkey.conf:
=================================
#!/usr/sbin/setkey -f
#
 
flush;
spdflush;
 
# Create security policies for racoon
# By not specifying any SA's (Security Associations), the
# kernel will use racoon to establish them.
 
spdadd 10.1.1.1/8 10.1.1.1/8 132 -P out ipsec
        esp/transport//require
        ah/transport//require;
 
spdadd 10.1.1.1/8 10.1.1.1/8 132 -P in ipsec
        esp/transport//require
        ah/transport//require;
=====================================

racoon.conf:
=====================================
path certificate "/etc/ipsec";
 
remote anonymous {
        exchange_mode main;
        dpd_delay 15;
        dpd_retry 5;
        dpd_maxfail 2;
 
        my_identifier asn1dn;
        peers_identifier asn1dn;
        verify_identifier on;
        certificate_type x509 "client1_cert.pem"
"client1_key.pem";
 
        proposal {
                lifetime time 24 hours;
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group modp1024;
        }
}
 
sainfo anonymous {
        lifetime time 8 hours;
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}
=====================================

Thanks in advance for your help. I'll be happy to
provide any additional information.

Tim Wilson

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1385632&group_id=74601