Re: issue with reflexsive access-list

:-)

Its simple. When you configure your reflexive ACL, you have 2 ACLs applied
to 2 interfaces; the inside and the outside (if you will) interfaces. When
the traffic comes in via the inside interface, it dynamically creates
entries on the outside ACL (which is normal operation of reflexive ACLs).
All other traffic that does not come in via the inside interface (and this
include locally generated traffic), there would not be entries in the
outside ACL to permit this traffic back in.

Therefore when your locally generated traffic leaves the router, it will be
blocked by the outside ACL when it returns to the router. To work around
this, you needed to find a way to make your local traffic create an entry
in the reflexive ACL. Hence I suggested to send the traffic to the loopback
interface after applying the inside ACL to the loopback interface.

This is the same reason that requires the outside ACL to statically allow
routing protocol traffic (if configured) on a outside ACL.

HTH
Sadiq

On Tue, Jul 31, 2012 at 3:52 PM, shekhar sharma
<shekhar.sharma21_at_gmail.com>wrote:

> No brother ,,,, i am not working for NASA as of now ..... :)
>
> Here is my runnig-config......
>
> your below solution is working ,,,,,But why its not working other way....??
>
> R1#sh running-config
> Building configuration...
> Current configuration : 1780 bytes
> !
> version 12.4
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> !
> hostname R1
> !
> boot-start-marker
> boot-end-marker
> !
> !
> no aaa new-model
> memory-size iomem 5
> ip cef
> !
> !
> !
> !
> no ip domain lookup
> !
> multilink bundle-name authenticated
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> archive
> log config
> hidekeys
> !
> !
> !
> !
> !
> policy-map mark
> class class-default
> set dscp 21
> !
> !
> !
>
> !
> !
> interface Loopback0
> ip address 150.1.1.1 255.255.255.0
> ip access-group inside_in in
> !
> interface FastEthernet0/0
> ip address 180.1.17.1 255.255.255.0
> ip access-group inside_in in
> duplex auto
> speed auto
> service-policy output mark
> !
> interface Serial0/0
> no ip address
> encapsulation frame-relay IETF
> frame-relay interface-dlci 113 ppp Virtual-Template1
> frame-relay lmi-type cisco
> !
> interface FastEthernet0/1
> no ip address
> shutdown
> duplex auto
> speed auto
> !
> interface Serial0/1
> ip address 180.1.31.1 255.255.255.0
> ip access-group outside_in in
> !
> interface Virtual-Template1
> ip address 180.1.13.1 255.255.255.0
> ip access-group outside_in in
> !
> router eigrp 100
> network 150.1.1.1 0.0.0.0
> network 180.1.13.1 0.0.0.0
> network 180.1.17.1 0.0.0.0
> network 180.1.31.1 0.0.0.0
> no auto-summary
> !
> ip local policy route-map local
> ip forward-protocol nd
> !
> !
> ip http server
> no ip http secure-server
> !
>
> ip access-list extended icmp_telnet
> permit tcp any any eq telnet
> permit icmp any any
> ip access-list extended inside_in
> permit ip any any reflect test
> ip access-list extended outside_in
> permit eigrp any any
> evaluate test
> !
> !
> !
> !
> route-map local permit 10
> match ip address icmp_telnet
> set interface Loopback0
> !
> !
> !
> !
> control-plane
> !
> !
> !
> !
> !
> !
> !
> !
> !
> !
> line con 0
> exec-timeout 0 0
> logging synchronous
> line aux 0
> line vty 0 4
> login
> !
> !
> end
>
>
> On Tue, Jul 31, 2012 at 6:29 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:
>
>> Since your config appears to be for a top-secret organization (and
>> therefore cannot be shared) :-)
>>
>> Try this:
>>
>> 1. set the next hop (more preferrably, set the interface in the PBR as
>> the loopback interface).
>> 2. apply the 'ip access-list extended inside_in' on the loopback
>> interface.
>>
>> This means your local traffic would hit your reflexive ACL and it should
>> work. Let us know what happens.
>>
>> Sadiq
>>
>>
>> On Tue, Jul 31, 2012 at 3:24 PM, shekhar sharma <
>> shekhar.sharma21_at_gmail.com> wrote:
>>
>>> i have tried it with next-hop 150.1.1.1 tooo already...
>>>
>>> still the same issue ... :(
>>>
>>> On Tue, Jul 31, 2012 at 6:22 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:
>>>
>>>> As far as I can see, 150.1.1.1 is a connected interface, but not
>>>> 150.1.1.254. When you do a show ip route 150.1.1.254, is falls under
>>>> 150.1.1.0/24, which is right. But that fact does not confirm if
>>>> 150.1.1.254 is a connected andvalid next hop for your PBR.
>>>>
>>>> Can we see the full config on R1?
>>>>
>>>>
>>>> On Tue, Jul 31, 2012 at 3:08 PM, shekhar sharma <
>>>> shekhar.sharma21_at_gmail.com> wrote:
>>>>
>>>>> Nops buddy...
>>>>>
>>>>> it is a connected interface
>>>>>
>>>>>
>>>>> R1#sh ip route 150.1.1.254
>>>>> Routing entry for 150.1.1.0/24
>>>>> Known via "connected", distance 0, metric 0 (connected, via
>>>>> interface)
>>>>> Redistributing via eigrp 100
>>>>> Routing Descriptor Blocks:
>>>>> * directly connected, via Loopback0
>>>>> Route metric is 0, traffic share count is 1
>>>>> R1#sh run itnloo
>>>>> R1#sh run int loo
>>>>> R1#sh run int loopback 0
>>>>> Building configuration...
>>>>> Current configuration : 63 bytes
>>>>> !
>>>>> interface Loopback0
>>>>> ip address 150.1.1.1 255.255.255.0
>>>>> end
>>>>>
>>>>> On Tue, Jul 31, 2012 at 6:03 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:
>>>>>
>>>>>> Hi Shekhar,
>>>>>>
>>>>>> Can we see the full config please? Is the next hop (150.1.1.254) on
>>>>>> R1 or another box which is the next hop? I suspect this is the reason (and
>>>>>> from what I see, its working as expected).
>>>>>>
>>>>>> If my assumption is right, then your local-policy is not making your
>>>>>> locally generated traffic hit the reflexive ACL (outside_in), mainly
>>>>>> because this does not pass through the inside_in ACL, to generate an entry
>>>>>> in the reverse direction.
>>>>>>
>>>>>> Anyway, hope that helps abit.
>>>>>>
>>>>>> Sadiq
>>>>>>
>>>>>> On Tue, Jul 31, 2012 at 2:56 PM, shekhar sharma <
>>>>>> shekhar.sharma21_at_gmail.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>>
>>>>>>> facing some issue with reflexsive access-list.
>>>>>>>
>>>>>>> The inbound to outbound & vice-versa restrictions is working fine....
>>>>>>>
>>>>>>> But not able to rectify router local generated traffic (ping &
>>>>>>> telnet) for
>>>>>>> mangement......after applying local policy..
>>>>>>>
>>>>>>> i am missing something basic here ... kindly help..
>>>>>>>
>>>>>>> configs :-
>>>>>>> 1) ip access-list extended inside_in
>>>>>>> permit ip any any reflect test
>>>>>>> 2) ip access-list extended outside_in
>>>>>>> permit eigrp any any
>>>>>>> evaluate test
>>>>>>>
>>>>>>> 3)ip access-list extended icmp_telnet
>>>>>>> permit tcp any any eq telnet
>>>>>>> permit icmp any any
>>>>>>>
>>>>>>> 4)#sh route-map
>>>>>>> route-map local, permit, sequence 10
>>>>>>> Match clauses:
>>>>>>> ip address (access-lists): icmp_telnet
>>>>>>> Set clauses:
>>>>>>> ip next-hop 150.1.1.254
>>>>>>> Policy routing matches: 119 packets, 7318 bytes
>>>>>>>
>>>>>>> 5)ip local policy route-map local
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> R1#ping 150.1.3.3
>>>>>>> Type escape sequence to abort.
>>>>>>> Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
>>>>>>> .....
>>>>>>> Success rate is 0 percent (0/5)
>>>>>>> R1#
>>>>>>> R1#
>>>>>>> R1#
>>>>>>> R1#
>>>>>>> R1#telnet 150.1.3.3
>>>>>>> Trying 150.1.3.3 ...
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> CCIEx2 (R&S|Sec) #19963
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> CCIEx2 (R&S|Sec) #19963
>>>>
>>>
>>>
>>
>>
>> --
>> CCIEx2 (R&S|Sec) #19963
>>
>
>

-- 
CCIEx2 (R&S|Sec) #19963
Blogs and organic groups at http://www.ccie.net