cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1703
Views
5
Helpful
8
Replies

Voice ACL

kris55s
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

Kristen

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.

HTH

Rick

HTH

Rick

View solution in original post

8 Replies 8

Richard Burts
Hall of Fame
Hall of Fame

Kristen

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.

HTH

Rick

HTH

Rick

Thank you. I had thought about them being reversed so I discussed it with our Cisco rep yesterday and this is how he told me to apply the in/out.

I'll try it.

Kristen

Give it a try and I think you will find it works the way I describe it. Or if still in doubt look at the logs and post some of the messages in the log which show traffic that is denied by either access list. A brief look at the log record noting which access list did the deny and what the source and destination addresses are should confirm the issue.

HTH

Rick

HTH

Rick

Kristen

I am glad that my responses helped you to resolve your issue. Thank you for using the rating system to indicate that your issue was resolved (and thanks for the rating). It makes the forum more useful when people can read about an issue and can know that they will read responses which did resolve the issue.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick

Thanks Rick. It worked.

I'm too accustomed to our PIX and don't do many ACL's on our switches, but I plan on doing alot more such as this.

I appreciate the explanation for in/out. That clarified it much better.

I'm back to square one. The phones stay operational unless they are power cycled or reset. If they are reset, they try to grab a data vlan IP address and can't register in CCM.

I'm at a loss now. I tried several different ACL's and I only get hits in the logging on the ones that I would think all it needs. This before I power cycle and the phone keeps it's voice vlan IP address.

Kristen

I am a bit confused. Your first paragraph seems to say that the phones do not work when you power cycle them. But the second paragraph seems to say that they do work. What am I missing?

I am not sure how you have changed the access lists and what access list you are using now. But it seems fairly clear that there is some address or some service that the phones need that is not permitted in the access list. So you need to find what else needs to be permitted.

In the access lists originally posted you were using the log parameter on all permits and on the denies. I would suggest that at this point logging the permits is not useful and tends to confuse what is going on. So I suggest that you set up your access list to not log permits and to log the packets that are denied. Then power cycle some phones. Then look in the logs for what is being denied. Hopefully you can identify what else needs to be permitted. If not then perhaps you can post some of the logs showing the traffic that is being denied.

[edit] my first guess would be to look for things like DNS, or TFTP, or maybe even DHCP.

HTH

Rick

HTH

Rick

The only thing I changed in the ACL's was added an acl for tftp. It did not make a difference.

I just ran another test with my phone, applied the ACL's that I used yesterday, power cycled my phone, and it did register in call manager, took longer than normal. I logged denies only and only saw a few denies that I should see.

I think there is a different issue going on with the other 2 phones. So, I'm going through a process of elimination.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco