Bug 217306

Summary: ifup-ipsec fails to establish a tunnel to PIX
Product: [Fedora] Fedora Reporter: Bojan Smojver <bojan>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: rvokal, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 16:57:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Script to manually bring the tunnel up none

Description Bojan Smojver 2006-11-26 21:14:12 UTC
Description of problem:

If IPSec interface is configured like this:

------------------------------------
DEVICE=ipsec0
ONBOOT=no
SRC=<outside-ip-of-the-box>
SRCNET=<network-behind-the-box>
DST=<outside-ip-of-the-pix>
DSTNET=<network-behind-the-pix>
IKE_PSK="somethingverysecret"
AH_PROTO=md5
TYPE=IPSEC
------------------------------------

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
-of-the-box[500]<=>outside-ip-of-the-pix[500]
------------------------------------

When started manually, the tunnel comes up just fine:

------------------------------------
Nov 27 07:52:50 beauty racoon: INFO: @(#)ipsec-tools 0.6.5
(http://ipsec-tools.sourceforge.net) 
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:
outside-ip-of-the-box[500]<=>outside-ip-of-the-pix[500] 
Nov 27 07:52:59 beauty racoon: INFO: begin Aggressive mode. 
Nov 27 07:52:59 beauty racoon: INFO: received Vendor ID:
draft-ietf-ipsra-isakmp-xauth-06.txt 
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
outside-ip-of-the-box[500]-outside-ip-of-the-pix[500]
spi:.................................
------------------------------------

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

How reproducible:
Always.

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:

http://www.redhat.com/archives/fedora-devel-list/2006-October/msg00178.html

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 21:14:12 UTC
Created attachment 142137 [details]
Script to manually bring the tunnel up

Comment 2 Bojan Smojver 2006-11-26 22:11:27 UTC
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 19:01:12 UTC
What happens if you add 'AH_PROTO=none' to your config file?

Comment 4 Bojan Smojver 2006-11-27 20:59:57 UTC
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 21:07:08 UTC
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 21:56:59 UTC
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 22:00:23 UTC
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 22:06:54 UTC
I don't know much about IPSec at all. I just got that info from these docs:

http://lartc.org/howto/lartc.ipsec.automatic.keying.html
http://www.ipsec-howto.org/x299.html

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

http://www.redhat.com/archives/fedora-devel-list/2006-October/msg00178.html

Comment 10 Bill Nottingham 2006-11-27 22:25:53 UTC
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 22:43:24 UTC
Let me check that with our Cisco guy...

Comment 12 Bojan Smojver 2006-11-27 22:47:07 UTC
This would suggest PIX supports AH:

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_user_guide_chapter09186a008033a369.html

Just search for AH on the page.

Comment 13 Bill Nottingham 2006-11-27 22:51:55 UTC
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 22:57:02 UTC
I think our PIX is configured to do MD5 only. Checking with our Cisco guy again...

Comment 15 Bojan Smojver 2006-11-28 03:02:09 UTC
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 04:57:30 UTC
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
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.

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 16:57:40 UTC
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.