From: Mike Williams (ccie2be@swbell.net)
Date: Fri Jun 06 2003 - 01:49:34 GMT-3
Fabrice,
Just 'access-enable'.
Mike W.
-----Original Message-----
From: Fabrice Bobes [mailto:study@6colabs.com]
Sent: Thursday, June 05, 2003 11:02 PM
To: 'Mike Williams'
Subject: RE: Strange quirk in Dynamic ACLs?!?! (Not really)
Mike,
Just a thought: are you using "access-enable" or "access-enable host" in
your config?
Fabrice
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Mike Williams
Sent: Thursday, June 05, 2003 6:38 PM
To: CCIELab@Groupstudy.com
Subject: Strange quirk in Dynamic ACLs?!?! (Not really)
Get this........ working through a scenario using Dynamic ACLs. In this
situation, I've setup a router (R5) so that it denies telnet access to
R2 (150.50.100.2) from both R7 (150.50.7.7) and R8 (150.50.5.69).
access-list 101 dynamic R2-TELNET permit tcp host 150.50.7.7 host
150.50.100.2 eq telnet
access-list 101 deny tcp host 150.50.5.69 host 150.50.100.2 eq telnet
access-list 101 deny tcp host 150.50.7.7 host 150.50.100.2 eq telnet
access-list 101 permit ip any any
Now.... when I telnet into R5 from R7, I can authenticate, it
disconnects me, then telnet to R2 from R7. Here's the 'sh access-list'
from R5 after R7 authenticates:
R5#sh access-list
Extended IP access list 101
Dynamic R2-TELNET permit tcp host 150.50.7.7 host 150.50.100.2 eq
telnet
permit tcp host 150.50.7.7 host 150.50.100.2 eq telnet (20
matches) (time left 1746)
deny tcp host 150.50.5.69 host 150.50.100.2 eq telnet (4 matches)
deny tcp host 150.50.7.7 host 150.50.100.2 eq telnet (2 matches)
permit ip any any (200 matches)
(Ignore the number of matches shown here as I had to copy/paste this
output together to show what I saw) No problems so far. It appears as
if, by authenticating from R7, that the dynamic entry R2-TELNET was
simply copied over as a "temporary" ACL entry. So then I cleared the
dynamic entries ("clear access-template 101 R2-TELNET any any"), and
wanted to see what would happen if I tried to do this from R8. I was
under the assumption that if I authenticated from R8 that the dynamic
ACL entry would again be duplicated verbatim and R7 would be able to
telnet to R2.
When I connected to R5 from R8, I did the usual authentication and
disconnection. However, when I tried to telnet from R7 to R2, I was
denied, so I checked the access-list on R5 and found this:
R5#sh access-list
Extended IP access list 101
Dynamic R2-TELNET permit tcp host 150.50.7.7 host 150.50.100.2 eq
telnet
permit tcp host 150.50.5.69 host 150.50.100.2 eq telnet (20
matches) (time left 1672)
deny tcp host 150.50.5.69 host 150.50.100.2 eq telnet (4 matches)
deny tcp host 150.50.7.7 host 150.50.100.2 eq telnet (2 matches)
permit ip any any (200 matches)
Strangely enough, I could telnet then from R8 to R2. So I'm really
confused at why, when my dynamic entry specifically permits host
150.50.7.7 to telnet to 150.50.100.2, when I authenticated from R8 to R5
to "start" the dynamic entry, it chose to substitute the IP of R8 for
the 150.50.7.7 that I explicitly put in the dynamic ACL entry. This
isn't documented in the IOS Configuration Guide at all. I'm not
complaining as I enjoy really learning how this stuff works, but I'm
confused at how the docs would fail to mention this stuff (although I'm
willing to admit that perhaps it's documented somewhere that I haven't
seen, so if you know, please share).
Any thoughts on this behavior?
Mike W.
PS: Since writing this post (which I'm GOING to send, just because it
may be helpful to someone else) I reread the chapter on dynamic ACLs
from the DocCD. It generically talks about how a dyn ACL "temporarily
reconfigures" the ACL, etc... but only ONE place in the entire
"Configuring Lock-and-Key" IOS 12.2 document (page SC-196) that says
"The only values replaced in the temporary entry are the source or
destination address, depending on whether this access list was in the
input access list or output access list. All other attributes, such as
port, are ingerited from the main dynamic access list"
Wow....... Two sentences on this..... and even that is vague as to
which value (source/dest) is replaced on an input or output list (they
could have even used the word "respectively" at the end of the first
sentence and it would have been clear). So it would seem that since I
was using this ACL as an input ACL, it replaced the source address in my
dyn ACL entry with the source IP of the packet that authenticated.....so
I can only assume that if I was using this as an output ACL it would
replace the dest addr.
Mike W.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:53 GMT-3