From: SourceForge.net <no...@so...> - 2005-12-19 23:08:57
|
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 |
From: SourceForge.net <no...@so...> - 2005-12-25 08:04:21
|
Bugs item #1385632, was opened at 2005-12-19 17:08 Message generated for change (Settings changed) made by twilson100 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: 6 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 |
From: SourceForge.net <no...@so...> - 2006-01-11 18:36:29
|
Bugs item #1385632, was opened at 2005-12-19 17:08 Message generated for change (Comment added) made by twilson100 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: 6 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 ---------------------------------------------------------------------- >Comment By: tim wilson (twilson100) Date: 2006-01-11 12:36 Message: Logged In: YES user_id=1408734 Sorry for the miswording after "PROBLEM:" It should read: "PROBLEM: the traffic *from* the far end is not received by the near end application process..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1385632&group_id=74601 |
From: SourceForge.net <no...@so...> - 2006-01-11 18:36:34
|
Bugs item #1385632, was opened at 2005-12-19 17:08 Message generated for change (Comment added) made by twilson100 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: 6 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 ---------------------------------------------------------------------- >Comment By: tim wilson (twilson100) Date: 2006-01-11 12:36 Message: Logged In: YES user_id=1408734 Sorry for the miswording after "PROBLEM:" It should read: "PROBLEM: the traffic *from* the far end is not received by the near end application process..." ---------------------------------------------------------------------- Comment By: tim wilson (twilson100) Date: 2006-01-11 12:36 Message: Logged In: YES user_id=1408734 Sorry for the miswording after "PROBLEM:" It should read: "PROBLEM: the traffic *from* the far end is not received by the near end application process..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1385632&group_id=74601 |