Re: ACL on 9200L not working as expected

NotworkNetwork · ‎07-01-2025

I have the following ACL configured and applied to the interfaces that have smart light controllers connected to them, and only want to allow them to talk to the cloud services. However, Im seeing them try to chat to IPs outside of the ACL, which given the "deny" at the end of the ACL is somewhat puzzling. 24 hours later, I cant see any external comms on our firewall at all...

Hardly a complex ACL so dont know why its not doing as expected.. any ideas?

ip access-list extended ACL-LITEIP
10 remark Allow DNS (UDP port 53)
10 permit udp any any eq domain
20 remark Allow DHCP (client to server and server to client)
20 permit udp any eq bootpc any eq bootps
30 permit udp any eq bootps any eq bootpc
40 remark Allow sync.liteip.com (51.140.187.215) on TCP 80, 443
40 permit tcp any host 51.140.187.215 eq www
50 permit tcp any host 51.140.187.215 eq 443
60 remark Allow ws.liteip.com (51.219.231.143) on TCP 80, 443
60 permit tcp any host 51.219.231.143 eq www
70 permit tcp any host 51.219.231.143 eq 443
80 remark Allow ubuntu01.liteip.com (51.11.135.150) on TCP 443, 1883
80 permit tcp any host 51.11.135.150 eq 443
90 permit tcp any host 51.11.135.150 eq 1883
100 remark Allow mqtt01.liteip.com (51.142.155.178) on TCP 443, 8883
100 permit tcp any host 51.142.155.178 eq 443
110 permit tcp any host 51.142.155.178 eq 8883
120 remark Allow EnergyHours.liteip.com (51.142.224.163) on TCP 80, 443
120 permit tcp any host 51.142.224.163 eq www
130 permit tcp any host 51.142.224.163 eq 443
140 remark Block all other traffic
140 deny ip any any

This has been applied to the interfaces

ip access-group ACL-LITEIP out

Thanks

Enes Simnica · ‎07-01-2025

The issue likely stems from how the acl is applied and how IoT devices operate. Since ur ACL is applied only in the outbound direction (out/), it doesn't block incoming traffic to ur controllers. The devices might be receiving responses or unsolicited traffic from other IPs that aren't filtered by this ACL.

Key points to check:

The acl/ is stateless - it doesn't automatically allow return traffic for permitted connections. Consider adding "permit tcp any any established" to handle response packets.
Cloud services often use multiple IPs or CDNs. The static IPs in ur ACL might be incomplete if the services expanded their infrastructure.
Common IoT requirements like NTP (UDP 123) are missing, which might explain some blocked traffic attempts.
For better visibility, add logging to ur deny rule ("deny ip any any log") to identify what's being blocked.

also the 24/hour communication drop suggests the devices might be failing over to alternative methods when primary connections fail. Review logs and consider expanding the ACL to cover all necessary cloud IPs and protocols.

if u need help configuring or troubleshooting further,,,,,,,,,, let me know. and hope it helps.

-Enes

more Cisco?!
more Gym?!

MHM Cisco World · ‎07-01-2025

Try use

Ip access-list standard 10

Permit ip <host>

Then

Debug ip packets access list 10

See which IP host try to connect

Note:- dont use debug without acl

MHM

BrokenViking · ‎07-01-2025

@NotworkNetwork MyLabCorp wrote:
I have the following ACL configured and applied to the interfaces that have smart light controllers connected to them, and only want to allow them to talk to the cloud services. However, Im seeing them try to chat to IPs outside of the ACL, which given the "deny" at the end of the ACL is somewhat puzzling. 24 hours later, I cant see any external comms on our firewall at all...
Hardly a complex ACL so dont know why its not doing as expected.. any ideas?
ip access-list extended ACL-LITEIP
10 remark Allow DNS (UDP port 53)
10 permit udp any any eq domain
20 remark Allow DHCP (client to server and server to client)
20 permit udp any eq bootpc any eq bootps
30 permit udp any eq bootps any eq bootpc
40 remark Allow sync.liteip.com (51.140.187.215) on TCP 80, 443
40 permit tcp any host 51.140.187.215 eq www
50 permit tcp any host 51.140.187.215 eq 443
60 remark Allow ws.liteip.com (51.219.231.143) on TCP 80, 443
60 permit tcp any host 51.219.231.143 eq www
70 permit tcp any host 51.219.231.143 eq 443
80 remark Allow ubuntu01.liteip.com (51.11.135.150) on TCP 443, 1883
80 permit tcp any host 51.11.135.150 eq 443
90 permit tcp any host 51.11.135.150 eq 1883
100 remark Allow mqtt01.liteip.com (51.142.155.178) on TCP 443, 8883
100 permit tcp any host 51.142.155.178 eq 443
110 permit tcp any host 51.142.155.178 eq 8883
120 remark Allow EnergyHours.liteip.com (51.142.224.163) on TCP 80, 443
120 permit tcp any host 51.142.224.163 eq www
130 permit tcp any host 51.142.224.163 eq 443
140 remark Block all other traffic
140 deny ip any any

This has been applied to the interfaces
ip access-group ACL-LITEIP out
Thanks

Great breakdown — that actually makes a lot of sense. I hadn’t considered the stateless nature of the ACL and how that might be affecting return traffic. Adding a permit tcp any any established rule is a smart move. Also good call on the cloud IP ranges — I’ll definitely check if the services have updated their infrastructure or CDN endpoints.

The note about missing NTP (UDP 123) is also helpful — easy to overlook, but critical for IoT devices. I’ll enable logging on the deny rule to get more insight into what’s being blocked.

Appreciate the help — this gives me a solid direction to troubleshoot further. I might reach out again if I hit another wall!

NotworkNetwork · ‎07-02-2025

Thanks for all the advice.. Ill try to work through this over the next couple of days and report back!

Richard Burts · ‎07-03-2025

We do not have much information about your environment and that impacts our ability to give good advice. If we had more information we might be able to help you better. But based on what we know so far, here is my suggestion: it looks like the acl is intended to filter traffic from connected devices going to destinations that are outside/public. In that case I would expect the acl to be applied out rather than in.

If you do show access-list do any of the entries have matches?

HTH

Rick