cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
905
Views
1
Helpful
20
Replies

Policy based routing with reflective ACL not working as expected

Karl3
Level 1
Level 1

Hi everyone. I have a 2960x acting as a "core" switch doing inter-vlan routing. Vlan 400 is for IoT. Other vlan hosts need to be able to access hosts in the iot vlan, no hosts in the iot vlan can access anything but internet. All hosts in the Iot vlan need to access the internet through an external VPN gateway on 172.16.30.42.
After configuring PBR, it works as expected. But when configured with reflactive ACL, things didn't work as expected.

configs:

ip access-list extended iot-1-in
5 evaluate iot-1-in-refl
10 deny ip any 10.0.0.0 0.255.255.255 log
20 deny ip any 172.16.0.0 0.15.255.255 log
30 deny ip any 192.168.0.0 0.0.255.255 log
40 permit ip any any

ip access-list extended iot-1-out
10 permit ip any any log reflect iot-1-in-refl

ip access-list extended vpn-pbr-acl1
10 deny ip any 10.0.0.0 0.255.255.255
20 deny ip any 172.16.0.0 0.15.255.255
30 deny ip any 192.168.0.0 0.0.255.255
40 permit ip any any

route-map vpn-pbr1 permit 10
match ip address pbr-acl1
set ip next-hop 172.16.30.42

interface Vlan400
ip address 172.16.4.1 255.255.255.240
ip access-group iot-1-in in
ip access-group iot-1-out out
ip policy route-map vpn-pbr1

 

The PBR config works as expected, but reflective ACL don't.

- Hosts in the IoT vlan can ping internet, and cannot ping LAN addresses.
- Hosts not in the IoT vlan cannot ping hosts in IoT vlan

When I remove `ip policy route-map vpn-pbr1` the reflective ACL works as expected, but internet traffic no longer goes to the VPN gateway

When the route-map is in place, this is what shows when showing access-lists

Extended IP access list iot-1-in
5 evaluate iot-1-in-refl
10 deny ip any 10.0.0.0 0.255.255.255 log
20 deny ip any 172.16.0.0 0.15.255.255 log (1041 matches)
30 deny ip any 192.168.0.0 0.0.255.255 log
40 permit ip any any
Reflexive IP access list iot-1-in-refl
permit icmp host 172.16.4.2 host 172.16.3.2 log (2037 matches) (time left 299)
Extended IP access list iot-1-out
10 permit ip any any reflect iot-1-in-refl log (1019 matches)
Extended IP access list vpn-pbr-acl1
10 deny ip any 10.0.0.0 0.255.255.255
20 deny ip any 172.16.0.0 0.15.255.255
30 deny ip any 192.168.0.0 0.0.255.255
40 permit ip any any

Why is it matching a permit on the reflexive ACL yet it is matched again on sequence number 20 on iot-1-in. Also one of the things I encountered is that the implicit deny seems to not exists(allowing all traffic on empty access-list)

What have I missed on these 2 components and why is have of the things configured not work as expected.

Version:

Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(7)E12, RELEASE SOFTWARE (fc5) on WS-C2960X-24PS-L
20 Replies 20

I am not clear if it is still relevant, but I will observe that in a previous post in this discussion this was posted 

Aug 8 11:32:29.598: %ACLMGR-3-INVALIDPARAM: Invalid ACL type 5 encountered
-Traceback= 7E98DCz 33BDF60z 3385AA0z 3B94FDCz 3B90CCCz

Any time that you get a traceback it is an indication of a software malfunction (aka bug). In this case I am not clear whether this might be a version dependent thing (might work in some versions but not in this version) or is a not supported thing.

HTH

Rick

According to
https://web.archive.org/web/20241119125514/https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/security/configuration_guide/b_sec_152ex_2960-x_cg/b_sec_152ex_2960-x_cg_chapter_01011.html#concept_896E426C1E5E40D18F46C16...
Section IPv4 ACL Switch Unsupported Features. 

  • Reflexive ACLs and dynamic ACLs are not supported.

So in this case I think IOS is allowing you to configure these features, but are not supported. Based on the behavior of the switch in the previous configs. It is not surprising that it wouldn't work now that I this document is found.

And in the newer 15.2 configuration guide, https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_7_e/configuration_guide/b_1527e_consolidated_2960x_cg.pdf, section, IPv4 ACL Switch Unsupported Features, Reflexive ACLs is also in one of the unsupported features.

I have no idea why it is possible to use configure it when it is not supported. The reflect keyword is In the ACL (syntax) example as well IN THE SAME DOCUMENT!!!!

According to https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_7_e/configuration_guide/b_1527e_consolidated_2960x_cg.pdf reflictive ACL is not one of the supported features. IOS have the capability to configure and use it, but I don't think the hardware can do it.

WS-C2960X-24PS-L, IOS  Version 15.2(7)E12

 

Hello
based on the additional information you have provided- 
I would say you need to amended your PBR policy to accommodate traffic you wish NOT be policy routed- meaning  you would have two stanzas 
a deny statement matching on specific traffic  (permit acl) not be be pbr’d
Then a catch all permit statement to allow all other traffic to be policy routed

Route-map PBR deny 10
match xxxx

Route-map PBR permit 100 
Set ip next hop xxxx

As for your Refl-acl - as stated previously it may be unnecessary - a simple cbac acl allowing ā€œestablishedā€ tcp sections may be appropriate 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

This route-map makes more sense then having a single ACL controlling what's get routed and what's not. As for the refl-acl part, it is just not supported, but is is still possible to configure it and is in one of the ACL (syntax) example in the same document. 

Hello
I tend to disagree. having a deny clause that will filter or in your case not policy route and a permit catch all clause makes for a much clearer cfg to understand, instead have to work through an entire acl to see what is be denied and allowed. 

As for the reflective acl, i believe in this instance based on what you have posted its unnecessary and a single routed acl on the SVI would be more applicable. 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul