Thanks for the workaround, Steff... will check it out!
Susan
> -----Original Message-----
> From: Stephan Reiter [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 23, 2001 6:08 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Fw-1 fails with ACS radius
>
>
> Hey Susan,
>
> CISCO confirmed the problem with low-priority. Checkpoint got
> not back to me at all....
>
> But we found a solution:
> On the firewall in the objects.C file, after "props:", just
> enter a line with
> ":radius_ignore (80)".
>
> From then, no problems any longer and users are
> authentificated again using ACS 2.6.
>
> Steff
>
> Stephan Reiter
> Manager IT
>
> Phone: +49 681 210 0
> Fax: +49 681 210 1131
> Cellular +49 172 6868 868
> E-mail: [EMAIL PROTECTED]
> WWW: http://www.IDS-Scheer.DE
>
>
> >>> "Jones, Susan M" <[EMAIL PROTECTED]> 04/13/01 03:23pm >>>
> Hi Steff,
> After sitting down at the packet level and actually watching
> what was going
> on, we confirmed that the ACS 2.5 (and also ACS 2.6) was in
> fact passing a
> packet back to FW-1 indicating that the authentication was successful;
> HOWEVER, the access-accept packet included an extra attribute
> in it (as
> compared to the access-accept packet from ACS V2.4). Cisco
> confirmed the
> finding and found it to be a bug, to be fixed in V2.6(2)
> which to date has
> no estimated release date. Cisco said that they were using
> EAP attribute 80
> in conjunction with Aironet devices, somehow attribute 80 was getting
> included in ALL responses and should have only been included WHEN
> REQUESTED... some devices can handle (aka, disregard) the
> attribute, but the
> FW-1 (V3.0B) could not. The newer ACS version will address
> this issue and
> only send attribute 80 when requested.
>
> Susan
>
> > -----Original Message-----
> > From: Stephan Reiter [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 12, 2001 9:57 AM
> > To: [EMAIL PROTECTED]
> > Subject: Fw-1 fails with ACS radius
> >
> >
> > Hello,
> >
> > I know that this won't be what you expect it to be, but we
> > encounter the sam strange behaviour with ACS 2.6. It's
> > working fine with our "slave" ACS 2.3. The authentification
> > goes through (we use a SecurID server), but the answer never
> > goes back to the firewall.
> >
> > Have you got any solutions (I'll open a case with Checkpoint anyhow)
> >
> > TIA Steff
> >
> >
> >
> >
> > Hello list!
> > Need your expertise, please...
> >
> > Just did an upgrade to our CiscoSecureACS for NT box from
> > V.2.4 to V.2.5 in
> > order to support a CiscoVPN5000 concentrator we are testing out.
> >
> > We can confirm that the CiscoSecureACS successfully
> > authenticates users
> > through some of our perimeter devices using RADIUS (IETF),
> > and can even do
> > so with the additional use of token cards However, a
> > CheckPoint FW-1 box
> > on site running Security Policy and Software version 3.0B will not
> > authenticate. We can trace packets from/to the
> > CiscoSecureACS box and see
> > CiscoSecureACS responding to the requests, but the FW-1 just
> > doesn't seem to
> > understand the reply or acknowledge it as being successful.
> > CiscoSecureACS
> > logs do not indicate a failure and a 'radtest' at the
> CiscoSecure box
> > indicates authentication is successful (as does the token
> server), but
> > authentication attempts through FW-1 say 'Radius servers not
> > responding'.
> >
> > One thing we've noticed in comparing the packets of CS ACS
> > V.2.4 and V.2.5
> > is that the response packets from the CS ACS server V.2.5 are
> > *longer* than
> > in V.2.4 ... specifically, V.2.4 has reply packet length=28;
> > V.2.5 has reply
> > packet length=46
> >
> > Can anyone 1) clarify why and what changed re: the packet
> > size from V.2.4 to
> > V.2.5 and 2) suggest a solution, or offer explanation of what
> > might be going
> > on?
> >
> > THANKS!
> >
> >
> > Stephan Reiter
> > Manager IT
> >
> > Phone: +49 681 210 0
> > Fax: +49 681 210 1131
> > Cellular +49 172 6868 868
> > E-mail: [EMAIL PROTECTED]
> > WWW: http://www.IDS-Scheer.DE
> >
> >
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
