Prev: MPLS & IPSEC VPN
Next: caller ID with callmanager/communication manager express
From: Bob Simon on 23 Apr 2008 00:25
On Tue, 22 Apr 2008 18:42:02 -0400, News Reader <user(a)domain.null>
wrote:

>Bob Simon wrote:
>> On Tue, 22 Apr 2008 16:44:23 -0400, News Reader <user(a)domain.null>
>> wrote:
>>
>>> Bob Simon wrote:
>>>> 2600 with C2600-IK9O3S-M, Version 12.3(26)
>>>>
>>>> Access-list 102 is applied to the outside interface incoming. When I
>>>> type, "show access-list 102" I get varying output.
>>>>
>>>> I always get the numbered ACEs from the config. For example:
>>>> 10 permit tcp any host 192.168.0.20 eq smtp (1912 matches)
>>>> 20 permit tcp any host 192.168.0.20 eq www (41 matches)
>>>>
>>>> Most of the time there are a varying number of statements BEFORE the
>>>> first numbered ACE in the output. These statements are NOT in the
>>>> config. For example:
>>>> permit icmp any host 192.168.0.30 time-exceeded (1179 matches)
>>>> permit icmp any host 192.168.0.30 unreachable (5342 matches)
>>>> permit icmp any host 192.168.0.30 timestamp-reply
>>>> permit icmp any host 192.168.0.30 echo-reply (5304 matches)
>>>>
>>>> Has anyone seen this behavior before? Why are these statements
>>>> present in the "show access-list" command output?
>>> You are probably using ICMP inspection on one of the interfaces (e.g.:
>>> inbound on the LAN interface). Inspection creates dynamic ACEs in the
>>> return path so that you don't need to specifically configure static ACEs
>>> to accommodate return traffic.
>>>
>>> These entries will timeout according to inspection policy configured for
>>> the specific protocol (e.g.: ICMP).
>>>
>>> Authentication proxy (when implemented) also creates dynamic entries
>>> that are placed above those configured in you interface ACLs. Auth-proxy
>>> ACEs are typically downloaded from a RADIUS or TACACS+ server.
>>>
>>> Best Regards,
>>> News Reader
>>
>> Thanks! You are correct. The config includes these:
>> ip inspect name FW ftp
>> ip inspect name FW icmp
>> ip inspect name FW smtp
>> ip inspect name FW tcp
>> ip inspect name FW udp
>>
>> int F0/1
>> ip inspect FW out
>
>Although I know that inspection opens holes in the return path, I am not
>seeing entries such as those you've described when I use the show
>access-list command while inspected sessions are active. This leads me
>to believe the ACEs you are seeing may be attributable to another feature.
>
>Are you using authentication proxy or some other feature that downloads
>ACLs from an access control server?
>
>Have you seen the ICMP ACEs timeout?
>
>Are you generating enough outbound ICMP traffic to prevent them from
>timing out?
>
>Best Regards,
>News Reader

I opened a TAC case and the engineer says he's never seen this
behavior before. Since I've already uploaded a new IOS image, I'm
betting there is a hardware error - possibly bad memory. This is an
interesting problem. I'll let you know how it turns out.
Bob
From: Bod43 on 23 Apr 2008 05:09
On 23 Apr, 06:25, Bob Simon <nob...(a)nowhere.com> wrote:
> On Tue, 22 Apr 2008 18:42:02 -0400, News Reader <u...(a)domain.null>
> wrote:
>
>
>
>
>
> >Bob Simon wrote:
> >> On Tue, 22 Apr 2008 16:44:23 -0400, News Reader <u...(a)domain.null>
> >> wrote:
>
> >>> Bob Simon wrote:
> >>>> 2600 with C2600-IK9O3S-M, Version 12.3(26)
>
> >>>> Access-list 102 is applied to the outside interface incoming.  When I
> >>>> type, "show access-list 102" I get varying output.
>
> >>>> I always get the numbered ACEs from the config.  For example:
> >>>>     10 permit tcp any host 192.168.0.20 eq smtp (1912 matches)
> >>>>     20 permit tcp any host 192.168.0.20 eq www (41 matches)
>
> >>>> Most of the time there are a varying number of statements BEFORE the
> >>>> first numbered ACE in the output.  These statements are NOT in the
> >>>> config.  For example:
> >>>>      permit icmp any host 192.168.0.30 time-exceeded (1179 matches)
> >>>>      permit icmp any host 192.168.0.30 unreachable (5342 matches)
> >>>>      permit icmp any host 192.168.0.30 timestamp-reply
> >>>>      permit icmp any host 192.168.0.30 echo-reply (5304 matches)
>
> >>>> Has anyone seen this behavior before?  Why are these statements
> >>>> present in the "show access-list" command output?
> >>> You are probably using ICMP inspection on one of the interfaces (e.g.:
> >>> inbound on the LAN interface). Inspection creates dynamic ACEs in the
> >>> return path so that you don't need to specifically configure static ACEs
> >>> to accommodate return traffic.
>
> >>> These entries will timeout according to inspection policy configured for
> >>> the specific protocol (e.g.: ICMP).
>
> >>> Authentication proxy (when implemented) also creates dynamic entries
> >>> that are placed above those configured in you interface ACLs. Auth-proxy
> >>> ACEs are typically downloaded from a RADIUS or TACACS+ server.
>
> >>> Best Regards,
> >>> News Reader
>
> >> Thanks!  You are correct.  The config includes these:
> >> ip inspect name FW ftp
> >> ip inspect name FW icmp
> >> ip inspect name FW smtp
> >> ip inspect name FW tcp
> >> ip inspect name FW udp
>
> >> int F0/1
> >> ip inspect FW out
>
> >Although I know that inspection opens holes in the return path, I am not
> >seeing entries such as those you've described when I use the show
> >access-list command while inspected sessions are active. This leads me
> >to believe the ACEs you are seeing may be attributable to another feature..
>
> >Are you using authentication proxy or some other feature that downloads
> >ACLs from an access control server?
>
> >Have you seen the ICMP ACEs timeout?
>
> >Are you generating enough outbound ICMP traffic to prevent them from
> >timing out?
>
> >Best Regards,
> >News Reader
>
> I opened a TAC case and the engineer says he's never seen this
> behavior before.  Since I've already uploaded a new IOS image, I'm
> betting there is a hardware error - possibly bad memory.  This is an
> interesting problem.  I'll let you know how it turns out.
> Bob

This sort of behaviour does occur with reflexive ACLs.

You don't have any

permit ...... reflect 102 ! if I recall correctly

statements anywhere do you?



From: Bob Simon on 23 Apr 2008 08:33
On Wed, 23 Apr 2008 02:09:43 -0700 (PDT), Bod43(a)hotmail.co.uk wrote:

>On 23 Apr, 06:25, Bob Simon <nob...(a)nowhere.com> wrote:
>> On Tue, 22 Apr 2008 18:42:02 -0400, News Reader <u...(a)domain.null>
>> wrote:
>>
>>
>>
>>
>>
>> >Bob Simon wrote:
>> >> On Tue, 22 Apr 2008 16:44:23 -0400, News Reader <u...(a)domain.null>
>> >> wrote:
>>
>> >>> Bob Simon wrote:
>> >>>> 2600 with C2600-IK9O3S-M, Version 12.3(26)
>>
>> >>>> Access-list 102 is applied to the outside interface incoming. �When I
>> >>>> type, "show access-list 102" I get varying output.
>>
>> >>>> I always get the numbered ACEs from the config. �For example:
>> >>>> � � 10 permit tcp any host 192.168.0.20 eq smtp (1912 matches)
>> >>>> � � 20 permit tcp any host 192.168.0.20 eq www (41 matches)
>>
>> >>>> Most of the time there are a varying number of statements BEFORE the
>> >>>> first numbered ACE in the output. �These statements are NOT in the
>> >>>> config. �For example:
>> >>>> � � �permit icmp any host 192.168.0.30 time-exceeded (1179 matches)
>> >>>> � � �permit icmp any host 192.168.0.30 unreachable (5342 matches)
>> >>>> � � �permit icmp any host 192.168.0.30 timestamp-reply
>> >>>> � � �permit icmp any host 192.168.0.30 echo-reply (5304 matches)
>>
>> >>>> Has anyone seen this behavior before? �Why are these statements
>> >>>> present in the "show access-list" command output?
>> >>> You are probably using ICMP inspection on one of the interfaces (e.g.:
>> >>> inbound on the LAN interface). Inspection creates dynamic ACEs in the
>> >>> return path so that you don't need to specifically configure static ACEs
>> >>> to accommodate return traffic.
>>
>> >>> These entries will timeout according to inspection policy configured for
>> >>> the specific protocol (e.g.: ICMP).
>>
>> >>> Authentication proxy (when implemented) also creates dynamic entries
>> >>> that are placed above those configured in you interface ACLs. Auth-proxy
>> >>> ACEs are typically downloaded from a RADIUS or TACACS+ server.
>>
>> >>> Best Regards,
>> >>> News Reader
>>
>> >> Thanks! �You are correct. �The config includes these:
>> >> ip inspect name FW ftp
>> >> ip inspect name FW icmp
>> >> ip inspect name FW smtp
>> >> ip inspect name FW tcp
>> >> ip inspect name FW udp
>>
>> >> int F0/1
>> >> ip inspect FW out
>>
>> >Although I know that inspection opens holes in the return path, I am not
>> >seeing entries such as those you've described when I use the show
>> >access-list command while inspected sessions are active. This leads me
>> >to believe the ACEs you are seeing may be attributable to another feature.
>>
>> >Are you using authentication proxy or some other feature that downloads
>> >ACLs from an access control server?
>>
>> >Have you seen the ICMP ACEs timeout?
>>
>> >Are you generating enough outbound ICMP traffic to prevent them from
>> >timing out?
>>
>> >Best Regards,
>> >News Reader
>>
>> I opened a TAC case and the engineer says he's never seen this
>> behavior before. �Since I've already uploaded a new IOS image, I'm
>> betting there is a hardware error - possibly bad memory. �This is an
>> interesting problem. �I'll let you know how it turns out.
>> Bob
>
>This sort of behaviour does occur with reflexive ACLs.
>
>You don't have any
>
> permit ...... reflect 102 ! if I recall correctly
>
>statements anywhere do you?
>
There are no reflexive ACL statements.

Late last night, the TAC engineer called me back. He had consulted
with someone in the security group who stated that this behavior is
normal with inspection. Apparently the original engineer was as
unfamiliar with this feature as I was.

Immediately after we applied the ACL to the interface with an
access-group statement, we observed many many un-numbered ACEs ahead
of the sequenced (expected) ACEs in response to "show access-list
102". There may have been hundreds of these (mostly) ICMP entries.

To News Reader: I have no idea why you did not see this behavior when
you looked for it in your router. Thanks for checking but I'm told
that it's normal in spite of the fact that it looks very odd.
From: Bod43 on 24 Apr 2008 03:57
On 23 Apr, 14:33, Bob Simon <nob...(a)nowhere.com> wrote:
> On Wed, 23 Apr 2008 02:09:43 -0700 (PDT), Bo...(a)hotmail.co.uk wrote:
> >On 23 Apr, 06:25, Bob Simon <nob...(a)nowhere.com> wrote:
> >> On Tue, 22 Apr 2008 18:42:02 -0400, News Reader <u...(a)domain.null>
> >> wrote:

> To News Reader: I have no idea why you did not see this behavior when
> you looked for it in your router.  Thanks for checking but I'm told
> that it's normal in spite of the fact that it looks very odd.

I am pretty sure that Cisco re-implemented a lot of the
inspect stuff in 12.3T sort of time.
If I recall correctly early 837s were "old" and about 4
years ago there were "new" ones.

Maybe the two of you are using different code?

First  |  Prev  | 
Pages: 1 2
Prev: MPLS & IPSEC VPN
Next: caller ID with callmanager/communication manager express