@MHM Cisco World wrote:You see automatic reflexive acl add it include icmp that wrong it need to be icmp reply.
Reflexive IP access list iot-1-in-refl
permit icmp host 172.16.4.2 host 172.16.3.2 log (4 matches) (time left 299)One more note:- remove log from outbound access-list.
I think it is just not displaying it properly, when I tried pinging back from 172.16.4.2 to 172.16.3.2, the icmp message is blocked. I forgot to mention, when an ICMP is packet is blocked, I get this message back
From 172.16.4.1 icmp_seq={} Packet filtered
so I think the switch is not displaying the entries properly. I though this Packet filtered reply was normal so I didn't mention it before. The reason for the log is to make it work, without it, the ACL would not work. Without the log arg, pinging from outside the IoT vlan does not trigger the Packet filtered message, just no reply, also the matches on seq:20 in the iot-1-in ACL is going up, so I think the ICMP reply message is blocked by that rule. The seq:10 rule in the iot-1-out ACL is not matching anything.
For a sanity check, I created a web server on 2 host, one inside the vlan, one outside.
With the setup
ip access-list extended iot-1-out
permit ip any any reflect iot-1-in-refl
The host outside the IoT vlan times out when trying to access the web server
Extended IP access list iot-1-in
10 evaluate iot-1-in-refl
20 deny ip any 10.0.0.0 0.255.255.255
30 deny ip any 172.16.0.0 0.15.255.255 (42 matches)
40 deny ip any 192.168.0.0 0.0.255.255
50 permit ip any any
Reflexive IP access list iot-1-in-refl
Extended IP access list iot-1-out
10 permit ip any any reflect iot-1-in-refl
When using
ip access-list extended iot-1-out
permit ip any any log reflect iot-1-in-refl
The host outside the IoT vlan, can access the web server inside the IoT vlan
Extended IP access list iot-1-in
10 evaluate iot-1-in-refl
20 deny ip any 10.0.0.0 0.255.255.255
30 deny ip any 172.16.0.0 0.15.255.255 (1 match)
40 deny ip any 192.168.0.0 0.0.255.255
50 permit ip any any
Reflexive IP access list iot-1-in-refl
permit tcp host 172.16.4.2 eq www host 172.16.3.2 eq 52616 log (13 matches) (time left 3)
Extended IP access list iot-1-out
10 permit ip any any reflect iot-1-in-refl log (8 matches)
The reason, I think, in theory is that the ASIC that process ACLs cannot handle reflective-acl, but the CPU can, by having the log argument, the frame/packet is not directly handled by the ASICs, but is directed to the CPU for processing. This would explain why
%ACLMGR-3-INVALIDPARAM: Invalid ACL type 5 encountered
not appearing when, the log arg is not set. Apologies if I didn't mention that before. I think when the ACL filtering is done on the ASIC, the CPU is not involved, the ASIC not being able to handle reflective-acl would also explain why the frame/packet gets match both on both seq:5,20 on the first post
@Karl3 wrote:
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
The ASIC treated the ACL like a normal ACL, incrementing the counter on the rule in iot-1-in-refl but also not knowing what to do with it and continue on matching seq:20.
Another thing that seems similar is when using object-group to define networks.
object-group network rfc1918
10.0.0.0 255.255.255.255
172.16.0.0 255.240.0.0
192.168.0.0 255.255.255.0
ip access-list extended iot-1-in
evaluate iot-1-in-refl
deny ip any object-group rfc1918
permit ip any any
ip access-list extended iot-1-out
permit ip any any log reflect iot-1-in-refl
ip access-list extended vpn-pbr-acl1
deny ip any object-group rfc1918
permit ip any any
With this applied, the both inbound and outbound acl gets ignored, with the PBR acl getting matched on permit ip any any when fetching the web server in the IoT vlan.
Extended IP access list iot-1-in
10 evaluate iot-1-in-refl
20 deny ip any object-group rfc1918
30 permit ip any any
Reflexive IP access list iot-1-in-refl
Extended IP access list iot-1-out
10 permit ip any any reflect iot-1-in-refl
Extended IP access list vpn-pbr-acl1
10 deny ip any object-group rfc1918
20 permit ip any any (12 matches)
I proceeded to add the log argument to the rules with object-group
ip access-list extended iot-1-in
evaluate iot-1-in-refl
deny ip any object-group rfc1918 log
permit ip any any
ip access-list extended iot-1-out
permit ip any any log reflect iot-1-in-refl
ip access-list extended vpn-pbr-acl1
deny ip any object-group rfc1918 log
permit ip any any
The accessing the web server in the IoT vlan did not work and same result as before, the host in the IoT vlan can access any ware without restriction as if the ACLs didn't exists.
Extended IP access list iot-1-in
10 evaluate iot-1-in-refl
20 deny ip any object-group rfc1918 log
30 permit ip any any (4 matches)
Reflexive IP access list iot-1-in-refl
permit tcp host 172.16.4.2 eq www host 172.16.3.2 eq 34080 log (5 matches) (time left 288)
permit tcp host 172.16.4.2 eq www host 172.16.3.2 eq 47350 log (31 matches) (time left 290)
permit tcp host 172.16.4.2 eq www host 172.16.3.2 eq 52086 log (26 matches) (time left 143)
permit tcp host 172.16.4.2 eq www host 172.16.3.2 eq 34026 log (1 match) (time left 77)
Extended IP access list iot-1-out
10 permit ip any any reflect iot-1-in-refl log (24 matches)
Extended IP access list vpn-pbr-acl1
10 deny ip any object-group rfc1918 log
20 permit ip any any (43 matches)
PBR no longer routes internet traffic to the gateway, but that's some what to be expected, PBR need IP ACL, so I switch back to not using object-group
ip access-list extended iot-1-in
evaluate iot-1-in-refl
deny ip any object-group rfc1918 log
permit ip any any
ip access-list extended iot-1-out
permit ip any any log reflect iot-1-in-refl
ip access-list extended vpn-pbr-acl1
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
The internet traffic from the IoT vlan gets routed to the gateway, but the 2 in/out ACL no longer have any effecy. None of the ACL hava any effects as if they don't even exists if object-group is defined.
So far the only config that works is
ip access-list extended iot-1-in
evaluate iot-1-in-refl
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
ip access-list extended iot-1-out
permit ip any any log reflect iot-1-in-refl
ip access-list extended vpn-pbr-acl1
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
