Bug 217306 - ifup-ipsec fails to establish a tunnel to PIX
ifup-ipsec fails to establish a tunnel to PIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2006-11-26 16:14 EST by Bojan Smojver
Modified: 2014-03-16 23:04 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 12:57:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Script to manually bring the tunnel up (737 bytes, text/plain)
2006-11-26 16:14 EST, Bojan Smojver
no flags Details

  None (edit)
Description Bojan Smojver 2006-11-26 16:14:12 EST
Description of problem:

If IPSec interface is configured like this:


Connection to PIX (ifup ipsec0) fails with (following repeated multiple times in
the log):

Nov 27 07:34:36 beauty racoon: ERROR: phase2 negotiation failed. 
Nov 27 07:34:41 beauty racoon: INFO: respond new phase 2 negotiation: outside-ip

When started manually, the tunnel comes up just fine:

Nov 27 07:52:50 beauty racoon: INFO: @(#)ipsec-tools 0.6.5
Nov 27 07:52:50 beauty racoon: INFO: @(#)This product linked OpenSSL 0.9.8b 04
May 2006 (http://www.openssl.org/) 
Nov 27 07:52:51 beauty racoon: INFO: outside-ip-of-the-box[500] used as isakmp p
ort (fd=7) 
Nov 27 07:52:51 beauty racoon: INFO: outside-ip-of-the-box[500] used for NAT-T 
Nov 27 07:52:59 beauty racoon: INFO: IPsec-SA request for outside-ip-of-the-pix
queued due to no phase1 found. 
Nov 27 07:52:59 beauty racoon: INFO: initiate new phase 1 negotiation:
Nov 27 07:52:59 beauty racoon: INFO: begin Aggressive mode. 
Nov 27 07:52:59 beauty racoon: INFO: received Vendor ID:
Nov 27 07:52:59 beauty racoon: INFO: received Vendor ID: DPD 
Nov 27 07:52:59 beauty racoon: INFO: received Vendor ID: CISCO-UNITY 
Nov 27 07:52:59 beauty racoon: NOTIFY: couldn't find the proper pskey, try to
get one by the peer's address.
Nov 27 07:52:59 beauty racoon: INFO: ISAKMP-SA established

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Configure IPSec "interface" as described above.
2. Attempt to connect to PIX with "ifup ipsec0"

Actual results:
Connection fails. The error is probably due to use of manual, instead of
automatic keying. See link to the mailing list message.

Expected results:
Should work.

Additional info:
This bug was first discussed here:


See the attached manual script for what works. The configuration file for the
tunnel looks like this:

remote outside-ip-of-the-pix
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group 2 ;
Comment 1 Bojan Smojver 2006-11-26 16:14:12 EST
Created attachment 142137 [details]
Script to manually bring the tunnel up
Comment 2 Bojan Smojver 2006-11-26 17:11:27 EST
The problem could be in lines 108 and 109, where SPD_AH_IN/OUT get set to yes,
where they probably should be unset for automatic keying.
Comment 3 Bill Nottingham 2006-11-27 14:01:12 EST
What happens if you add 'AH_PROTO=none' to your config file?
Comment 4 Bojan Smojver 2006-11-27 15:59:57 EST
ERROR: reject the packet, received unexpecting payload type 0.

And then:

ERROR: phase2 negotiation failed due to time up waiting for phase1.

I think PIX only likes MD5 there.
Comment 5 Bill Nottingham 2006-11-27 16:07:08 EST
Whoops, I'm blind - that suggestion made no sense.

I'm not sure why requiring AH should make a difference there - it's just setting
it to allow AH.

Your script implies that it's not using AH at all, but when you set it to not
use AH, it fails?
Comment 6 Bojan Smojver 2006-11-27 16:56:59 EST
When running setkey, the AH bits are not necessary, as this will be done by
racoon, AFAIK. However, the AH_PROTO is still used to tell racoon what to use
(line 180: hash_algorithm $AH_PROTO;)

Note that if AH_PROTO is none, it gets set to sha1 (line 114 to 117). This is no
good for PIX - it only does MD5.

So, if AH_PROTO is md5 (like PIX likes it), the SPD_AH_IN/OUT get set to yes,
which then stuffs things up (i.e. racoon is supposed to do this, not setkey). If
set to none, it reverts to sha1, which is also no good for PIX.
Comment 7 Bill Nottingham 2006-11-27 17:00:23 EST
OK, now I'm confused. racoon is supposed to set its own spds for AH, but not for
ESP? That doesn't make sense to me.
Comment 8 Bojan Smojver 2006-11-27 17:06:54 EST
I don't know much about IPSec at all. I just got that info from these docs:

Comment 9 Bojan Smojver 2006-11-27 17:08:06 EST
The examples from these docs are quoted in my message to devel list:

Comment 10 Bill Nottingham 2006-11-27 17:25:53 EST
OK, stepping back for a second:

Does the PIX *actually support AH*? AH_PROTO=none sets a value in the racoon
config file, but doesn't actually set up any SPD definition for ESP.
racoon, as I understand it, does *not* add its own SPDs.
Comment 11 Bojan Smojver 2006-11-27 17:43:24 EST
Let me check that with our Cisco guy...
Comment 12 Bojan Smojver 2006-11-27 17:47:07 EST
This would suggest PIX supports AH:


Just search for AH on the page.
Comment 13 Bill Nottingham 2006-11-27 17:51:55 EST
True. I wonder if there are specifics in the PIX config, though. Interestingly,
that page says that it supports SHA-1.
Comment 14 Bojan Smojver 2006-11-27 17:57:02 EST
I think our PIX is configured to do MD5 only. Checking with our Cisco guy again...
Comment 15 Bojan Smojver 2006-11-27 22:02:09 EST
Just confirmed: the isakmp hash algorithm is set to MD5 for PSK authentication
on our PIX. That's why SHA1 doesn't work (although it's supported by PIX)
Comment 16 Bug Zapper 2008-04-04 00:57:30 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 17 Bug Zapper 2008-05-06 12:57:40 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.