I am trying to apply access-lists to deny any traffic from other vlans into my voice vlan. I do, however have to allow traffic to/from the DHCP server and the CCM and Unity servers which reside on another Voice subnet.
This is what I have applied. My VoIP phone goes to registering.
ip access-group 102 in
access-list 102 remark VOIP_security_ACL's in
access-list 102 permit ip host (DHCP server) xxx.xx.xx.xx (this voice subnet)xxx.xx.xx.0 0.0.1.255 log
access-list 102 permit ip (CCM and Unity subnet)xxx.xx.xxx.0 0.0.1.255 (this voice subnet)xxx.xx.xx.0 0.0.1.255 log
access-list 102 deny ip any any log
ip access-group 103 out
access-list 103 remark VOIP_security_ACL's out
access-list 103 permit ip (this voice subnet)xxx.xx.xx.0 0.0.1.255 host (DHCP server)xxx.xx.xx.xxx log
access-list 103 permit ip (this voice subnet)xxx.xx.xx.0 0.0.1.255 (CCM and Unity subnet)xxx.xx.xx.0 0.0.1.255 log
access-list 103 deny ip any any log
I have applied the access-group 102 in on the voice vlan first, waited, and phone goes to registering. I then applied the 103 out, and the phone never regains connectivity until 102 is removed.
I believe that the main issue is confusion about how in and out work with access lists. In and out are relative to the interface to the VLAN. So an access list "in" is traffic from the VLAN in to the switch/router interface and an access list "out" is traffic from the switch/router interface out to the VLAN. So your "in" access list should have the voice subnet as the source with DHCP/CCM as the destination. And your "out" access list should have DHCP/CCM as the source and the voice subnet as the destination. Your access lists are applied backward. I believe that you can confirm this by looking at the logs that are generated by the deny statements. Look for the source and destination addresses that are denied by 102 and by 103. You could fix this by applying 102 out and applying 103 in or you could re-write the logic of both access lists.
It may be possible that there is some service (I am not clear whether it would be DNS, or TFTP, or something else) that is needed that is not being permitted in your access list. Since your last line in the access list is deny ip any any log you should be able to look in the log messages for the traffic that is being denied and figure what else needs to be permitted.