[nsp] Filter-Id for AS5300
Srdjan Simic
srdjan at sezampro.yu
Fri Aug 1 14:15:11 EDT 2003
Hi,
No I am talking about vaccess on LNS. We are terminating L2TP users on 3640. When I do "sho ip int" there is access list, but I tried myself to connect and stuff that are supposed to be forbidden are not. Further more counters on incoming access lists are not incrementing and on outgoing are. It looks that something turned off in access list :) because there are some hits, but the numbers are way to low.
Regards Srdjan
-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
Sent: Friday, August 01, 2003 12:23 PM
To: Srdjan Simic; mtinka at africaonline.co.ug
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] Filter-Id for AS5300
Hi,
> After comparing this, I found out that access list are NOT applied
> to virtual-access interfaces, even though it says in the "sh ip int"
> output (on 12.3(1a)):
>
> Outgoing access list is f20po, default is not set
> Inbound access list is f20pi, default is not set
>
> I switched back to 12.2(8)T and filters work. We are using Radius
> code 11 (Filter-ID). We are using this for VPDN (L2TP).
Hmm, you are not trying to filter VPDN/L2TP users on the LAC, aren't
you? There is no vaccess interface on the LAC for the user as we don't
terminate the PPP connection, so you're probably talkin about a locally
terminated ppp user?!
Just checked with 12.3(1a) on an AS5300: per-user ACLs are correctly
applied and enforced on a vaccess. What makes you think they are not
applied/enforced?
See below..
oli
dialin1 Password = "test"
Service-Type=Framed-User
Framed-Protocol = PPP,
Framed-IP-Address="5.5.5.5",
Filter-Id="aclin.in",
Filter-Id="aclout.out",
Cisco-avpair="lcp:timeout=60"
AS5300B#sh ver | i IOS
IOS (tm) 5300 Software (C5300-IS-M), Version 12.3(1a), RELEASE SOFTWARE
(fc1)
AS5300B#sh ip int vi2 | i access list
Outgoing access list is aclout, default is not set
Inbound access list is aclin, default is not set
AS5300B#sh access-l
Extended IP access list aclin
10 deny ip any any (4 matches)
Extended IP access list aclout
10 deny ip any any
AS5300B#
*Feb 5 23:02:31.611: ICMP: dst (20.20.20.20) administratively
prohibited unreachable sent to 5.5.5.5
*Feb 5 23:02:32.123: ICMP: dst (20.20.20.20) administratively
prohibited unreachable sent to 5.5.5.5
*Feb 5 23:02:34.619: ICMP: dst (20.20.20.20) administratively
prohibited unreachable sent to 5.5.5.5
AS5300B#sh access-l
Extended IP access list aclin
10 deny ip any any (15 matches)
Extended IP access list aclout
10 deny ip any any
AS5300B#
*Feb 5 23:02:50.019: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:51.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:52.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:53.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:54.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:55.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
*Feb 5 23:02:56.011: ICMP: dst (5.5.5.5) administratively prohibited
unreachable sent to 10.0.0.8
AS5300B#sh access-l
Extended IP access list aclin
10 deny ip any any (15 matches)
Extended IP access list aclout
10 deny ip any any (14 matches)
AS5300B#
>
> -----Original Message-----
> From: Mark Tinka [mailto:mtinka at africaonline.co.ug]
> Sent: Friday, August 01, 2003 8:48 AM
> To: 'Oliver Boehmer (oboehmer)'; Srdjan Simic
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [nsp] Filter-Id for AS5300
>
>
> Oliver Boehmer (oboehmer) wrote:
> > Hi,
> >
> > I think we are talking about two different problems, even though
> > they look similar:
> >
> > > Srdjan Simic wrote:
> > > > We had the same problem. sh run did not show acl, but sh
> > > > access-list did, and besides the name there was "(per-user)".
> > > > This was with IOS 12.2(8)T and C3640. We were in big trouble,
> > > > because we could not save the config. After first lookups, it
> > > > seems that, when the router boots, everything is ok. When the
> > > > first user comes and requests a filter set, that filter set is
> > > > removed from running config. We switched to other IOS and that
> > > > solved the problem. Currently we are on 12.3(1a) but we also
> > > > tried 12.2(17a) and
> > > > 12.2(7a) .and
> >
> > This problem has been described in CSCdx52334 (and has been fixed in
> > 12.2(13)T/12.2(13) and other releases). Every per-user ACL
> > effectivly turned on the "per-user" flag on existing ACLs
> > configured on the box and thus prevented them from being saved
> > (per-user ACLs are dynamic and are never saved).
> >
> >
> > > So you say that after a reboot [I haven't yet tried], the
> > > configuration remains intact [albeit invisible], and that the
> > > named access list will work even when it doesn't show up in the
> > > running configuration.
> >
> > No, I doubt this, unless the ACL is present in the startup-config
> > (which it isn't if you did a "write" after the box booted).
> >
> > > Well, I am running 12.3(1a) too, but I am exhibiting this
> > > problem. I never tried using this named access list on my
> > > previous IOS, so I can't really say whether the problem is with
> > > 12.3.
> >
> > The behaviour you're seeing with 12.3(1a) is definitly a bug and
> > needs to be fixed. It could be a race condition, maybe some user's
> > profile referenced the ACL before or while (?) it was being defined.
> > I also saw this problem with 12.2(2)XB11, but only on one of 100+
> > routers using the same config.
> >
> > Can you please try the following: Use "copy tftp startup-config" to
> > write a complete config (including the ACL) directly into the NVRAM
> > and do a reload. The system will then come up with the ACL, and the
> > problem should be solved. If not, it would be very interesting to
> > see what triggered the problem, but might be difficult to find out.
> > I'll try to repro this internally..
> >
> > Tx,
> > oli
>
> Hi Oli. Thanks for your response.
>
> I did as you suggested, and copied the configuration from my TFTP
> server straight into NVRAM. I reloaded, and it works fine. The
> configuration is present in the running-config file, and the
> (per-user) flag is no longer present on the show access-list command:
>
> AS5300#sh access-lists emailonly
> Extended IP access list emailonly
> 10 permit tcp any any eq smtp (14 matches)
> 20 permit tcp any any eq pop3 (1207 matches)
> 30 permit tcp any any eq domain
> 40 permit udp any any eq domain (54 matches)
> 50 permit tcp any host x.x.x.x eq www
> 60 permit tcp any host x.x.x.x eq www
> 70 permit tcp any host x.x.x.x eq www
> 80 permit tcp any host x.x.x.x eq 443
> 90 permit icmp any any echo (2 matches)
> 100 permit icmp any any echo-reply
> 110 permit tcp any eq smtp any
> 120 permit tcp any eq pop3 any
> 130 permit tcp host x.x.x.x eq www any
> 140 permit tcp host x.x.x.x eq www any
> 150 permit tcp host x.x.x.x eq www any
> 160 permit tcp host x.x.x.x eq 443 any
> 170 permit tcp any eq domain any
> 180 permit udp any eq domain any
> 190 deny ip any any (429 matches)
> AS5300#
>
> Many thanks for this workaround.
>
> Regards,
>
> Mark Tinka - CCNA
> Network Engineer, Africa Online Uganda
More information about the cisco-nsp
mailing list