DHCP quits when ACL applied

[lhoyle]

I have a 1760 that routes traffic between 3 VLANS and the Internet. VLAN1 can also get to VLAN5 and VLAN10, but not the other way around. DHCP works fine until the ACL is placed on the subinterfaces of F0/0. Any help will be appreciated.

[Richard Burts]

Andy

Your point would be more valid if the access list were applied as inbound, in which case the DHCP must be permitted. But since the access list is applied out, and since an outbound access list does not check traffic generated by the router itself then I believe that DHCP would work without the modification to the access list.

HTH

Rick

[andrew.butterworth]

I only skimmed through the thread and didn't realise they were applied outbound.... My fault for not reading deep enough.

I thought you would still need the lines in there (reversed) even if the router is the DHCP server though? I have never seen a reference to the processing order showing that router generated traffic is exempt from outbound ACL processing?

Andy

[Richard Burts]

Andy

It is hard to find it written down clearly, but it is the case (and has always been the case) that an outbound access list will not filter traffic that is generated by the router itself. It is easy to check in the lab.

So as long as the router is the DHCP server there is no need to permit DHCP traffic in an outbound access list.

HTH

Rick

[andrew.butterworth]

You live and learn!!!!

I'll have a play around with this in the lab tomorrow as this is something that has somehow bypassed me (in all my years of doing this stuff...)

Andy

[lhoyle]

I really appreciate Andy and Rick's comments. They have been very beneficial for me! Thank you again!

[andrew.butterworth]

Just to finish this one off I tried this in the lab yesterday and it does indeed do what Rick said - i.e. router generated traffic bypasses egress ACL processing.

I have some autonomous WiFi AP's all connected to the same Layer-3 PoE switch, currently there is an inbound ACL attached the SVI that the 'Guest' SSID is bound to. This ACL allows some restictive access to Wireless 'Guests':

ip access-list extended Guest-Wireless

permit udp any any range bootps bootpc

permit udp 10.99.99.0 0.0.0.31 host 192.168.100.10 eq domain

deny ip any 192.168.0.0 0.0.255.255

permit tcp 10.99.99.0 0.0.0.31 gt 1023 any eq www

permit tcp 10.99.99.0 0.0.0.31 gt 1023 any eq 443

!

They can get an IP address via DHCP, use one of the internal DNS Servers for name resolution but can't reach any other internal host and then can use HTTP & HTTPS to hosts on the internet. I then created another ACL by reversing this one and also removing the DHCP entries (UDP 67-68). When this was then applied and a WiFi client disconnected and then re-connected it continued to work proving the DHCP responses were bypassing the egress ACL. I was a bit surprised at this at first as the DHCP server is somewhere else and not on the switch, however an IP Helper is configured on the SVI so the client DHCP broadcast packets are encapsulated by the SVI and unicast to the DHCP server that in turn replies via unicast to the switch. The switch then de-encapsulates the packet and unicasts it back to the DHCP client, so it is traffic generated by the router.

You learn something new everyday...

Andy

[Richard Burts]

Andy

Thanks for posting back with the results of your testing (and thanks for confirming what I had said). I agree that it is not the behavior that you would expect from a purely logical perspective (that an access list applied outbound would not filter traffic generated by the router). But it has consistently been the behavior of IOS.

HTH

Rick