From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko) Description of problem: I have an FC2 box that I'm trying to use racoon/setkey to connect to a FC3 box using openswan. The FC3 box has been running for some time with various VPN connections and is known to work. I was trying to setup the FC2 box using the init scripts provided that use ifup/down-ipsec. I was able to get the connection to the point where it would try to come up, but the SA was never completed using the default config. In the racoon config I had to make sure that it used main mode instead of aggressive. In the ifup-ipsec script (the part I don't like modifying), I had to modify the setkey options to not setup an AH connection and set the ESP connection to 'unique'. All my steps were helped with the instructions from this web page: http://www.purple.dropbear.id.au/node/view/64 I should note that this was all done with automatic keying and PSKs. Packages on each box are below. == FC3 Box using openswan == openswan-2.1.5-2.FC3.1 kernel-2.6.10-1.760_FC3 == FC2 Box using racoon/setkey == ipsec-tools-0.2.5-4 kernel-2.6.9-1.6_FC2 Version-Release number of selected component (if applicable): openswan-2.1.5-2.FC3.1 kernel-2.6.10-1.760_FC3 ipsec-tools-0.2.5-4 kernel-2.6.9-1.6_FC2 How reproducible: Always Steps to Reproduce: 1. Setup an open/freeswan server 2. Setup an fc2 server and configure the ifcfg-ipsec interface 3. Try to bring up the tunnel Actual Results: The tunnel fails to fully come up. Both sides get 'stuck'. Expected Results: Tunnel should come up with minimal config changes. Interop with openswan should be a design goal, I would think, since both are packaged with FC3. Additional info: I think modifying the $DST.conf file to change the exchange mode is fine. If there was some way to specify the setkey options in a generated file similar to the way the $DST.conf file is generated it would be much cleaner than modifying the ifup-ipsec.
Created attachment 111571 [details] FC3 Openswan Config Excerpt
Created attachment 111572 [details] FC3 Openswan Log when tunnel is trying to come up
Created attachment 111573 [details] FC2 Racoon ifcfg interface
Created attachment 111574 [details] FC2 Racoon modified $DST.conf
Created attachment 111575 [details] FC2 Racoon Log when tunnel is trying to come up
Created attachment 111576 [details] FC2 ifup-ipsec modified lines to make tunnel work
This FreeSWAN interoperability problem also exists in RHEL 3 and RHEL 4. Adding an option to the ifconfig-ipsec* configuration files that gets parsed by the ifup-ipsec script could help. That option should specify whether AH is required. It should be enabled by default, but you should be able to turn it off if your IPSEC peer does not support AH.
Created attachment 120854 [details] Patch to disable AH in RHEL4 Here's a patch vs. RHEL4 that disables AH completely. I would not propose including this patch directly, but instead to use it for testing so that a working ifup-ipsec that understands some sort of syntax in ifcfg-ipsec* similar to one of: # This option would require both AH and ESP (the status quo) POLICY_REQUIRE=AH+ESP # This option would require only ESP, yielding results similar to the # enclosed patch POLICY_REQUIRE=ESP
Note that I did not get racoon to completely interoperate with the patch that I posted on 2005-11-09, but it did help the key negotiation proceed farther than it had before.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp