+++ This bug was initially created as a clone of Bug #201853 +++ Description of problem: By ifup-ipsec created peer configuration, insecure aggressive mode is preferred against more secure main mode. Version-Release number of selected component (if applicable): ipsec-tools-0.3.3-6.rhel4.1 (RHEL) ipsec-tools-0.6.4-1.1 (FC5) How reproducible: Always Steps to Reproduce: 1. Create /etc/sysconfig/network-scripts/ifcfg-ipsec0 like SRC=192.0.2.1 DST=192.0.2.2 TYPE=IPSEC IKE_METHOD=PSK IKE_PSK=secret 2. ifup ipsec0 Actual results: remote 192.0.2.2 { exchange_mode aggressive, main; my_identifier address; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ; } } Expected results: remote 192.0.2.2 { exchange_mode main, aggressive; ... Additional info: Any good reason why the order is "aggressive, main"? If 2 hosts now using the same setup scripts (e.g. both are RH powered), aggressive mode would be used. Also it would be good if this can be controlled by a configuration parameter, e.g. IKE_MODE=aggressive|main|any --- Additional comment from pb on 2006-08-09 11:45:55 EDT --- BTW: would be great if other parameters would also be optionally configurable, e.g. - dh_group (2 = 1024 is also not so secure than upper ones). - lifetime Note also that for automatic keying, neither AH nor ESP can be selected for phase 2 (IPsec negotiation) and will always default to "sha1" and "3des-cbc" Topology part is completly missing in configuration like: # host-to-host sainfo address 192.0.1.1 any address 192.0.1.2 any { lifetime time 1 hour; encryption_algorithm 3des; authentication_algorithm hmac_md5 ; compression_algorithm deflate ; } --- Additional comment from notting on 2006-08-09 11:48:26 EDT --- It's done to decrease connection overhead; I can see making it a configuration parameter. However, I suspect the more complex of an ipsec configuration you have, the more likely it is that you should just edit raccoon.conf directly. --- Additional comment from pb on 2006-08-09 11:55:22 EDT --- Hmm, at least phase 2 should be supported in some way. Problem is, if I apply changes to the file 192.0.2.1.conf directly, they are overwritten, if ifcfg-ipsec0 is changed. And if I setup my own racoon.conf file, I run into the problem, that there is no standalone start script provided for racoon - and as I had to learn from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136901 this is a feature and not a bug... --- Additional comment from pb on 2006-08-10 05:48:53 EDT --- Created an attachment (id=133921) patch which adds support for some more IPsec parameters Following variables are now supported (and shown with an example): IKE_EXCHANGE_MODE=main IKE_DH_GROUP=5 IPSEC_ESP_PROTO=aes128 IPSEC_AH_PROTO=hmac_sha1 IPSEC_LIFETIME="1 hour" IPSEC_PFS_GROUP=5 --- Additional comment from pb on 2006-08-10 05:59:50 EDT --- Some forgotten comments: - patch is successfully tested in host-to-host mode, can't currently test for net-to-net mode - patch cotains also a fix that prevents creation of dedicated conf file with standard umask permissions 0644, it reduces this to 0600 like racoon.conf has set - if no of the new introduced parameters are given, still a topology would be created. This was shown as compatible here to a still unpatched ifup-ipsec file. But for clean backward compatibility, I will now provide a new version which explictly only creates topology, if one or more new introduced IPSEC* parameters are given. --- Additional comment from pb on 2006-08-10 06:01:04 EDT --- Created an attachment (id=133924) patch which adds support for some more IPsec parameters #2 --- Additional comment from notting on 2008-12-08 16:56:45 EDT --- This is unlikely to change for RHEL 4 at this point. I'm cloning this bug for the development stream.
Bill, was it solved? I will go to change it to Assigned, I'm not sure that was solved. Thanks.
Has not been applied yet.
*** Bug 497554 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 354123 [details] Updated patch against rawhide (initscripts-8.95.1) *** This problem is not yet resolved in rawhide *** The attached patch is adapted from the previous one (version 2) for the current script version. 2 fixes to the previous patch have been added: _ $MODE = 'host' cannot be true: replaced by $MODE = 'transport' _ In case $MODE = 'tunnel', "sainfo subnet" is used instead of "sainfo address" I hope it helps
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm deeply disappointed this 30 month old bug (yes, 2.5 years!) is still present (in version 9.30-1), although a patch fixing it has been provided... Trying to help with this important package feels like a pain in the ass: see also bugs 498472 and 665378 :-(( Resetting version to rawhide once again.
To be completely honest, ipsec-tools support is deprecated in favor of openswan; in that case we work by just having openswan configurations brought up by that package itself, not done through ifcfg files. The likely way forward is to move ifup/ifdown-ipsec to the ipsec-tools package itself.
> ... move ifup/ifdown-ipsec to the ipsec-tools package itself. Why not, if it can resolve this bug: IMHO, every solution is better than the current stalled situation.
Scripts have been moved in rawhide.
... and problem is still not fixed :-(
Now the main mode is preferred over the aggressive mode.
I've just seen it you fixed it. Many thanks :-)