Wireless Access

We are having an issue with calls not connecting from our corporate wireless network across multiple sites. It works fine from our guest network. Not sure if it's related to the controller or set up but just wanted to raise a ticket to check if there has been any VoIP related issues with version 8.4.0.3 when running an MM environment.

Also wanted to check if deep packet inspection causes any problems . We have had this enabled all along so don't think this is the problem unless there has been a change in code version of how this operates.

The two ssids are on the same controller pushed to all APs. Only difference is corporate authentication is done via 802.1x certificate via Microsoft NPS but users can connect and browse internet fine

Calls showing connected in the service dashboard but all showing length of around one minute and users calls are silent when answered. Not sure why this would work from one SSID but not another . Anyone heard of this or know how best to troubleshoot?

Thanks

What ACLs are mapped to the role assigned to the user?

 

This could be checked using the command show rights <role of the user>

 

If the role is not known, the command show user-table | include <ip of the user> could be used to find it out.

 

If you have pair of test users, map them to the default "Voice" role and check the behaviour.

 

The command " aaa user add <ip address of the user> voice " can be used to achieve this.

 

Also what is the status of the sessions of the user? Are the TOS values right for the protocol used?

 

Check the above using " show datapath session table <ip address of the user> "

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

 

 

Pretty basic acls that have always existed just to block traffic to the other subnets on the network for example block guest to corporate and vice versa. Then any any permit.

Most rules done on our firewall but nothing changed here .

Can you add a user to voice role if they need to be using 802.1x to authenticate though or will this change that role to voice ?

Thanks

Get Outlook for Android

You can change the role after authentication using that command.

 

Basically, have two test users authenticate, then add them to the voice role.

 

Then have a test call and check their specific session details using the command.

 

" show datapath session table <user 1 IP> | include <user 2 IP> "

 

Now perform the same test with your normal users in their normal role.

 

Compare the datapath session output and look for any blocked ports.

 

What protocol is being used? 

 

Have a look at the voice role, it gives you a basic idea of all the most-used protocols/ports for voice.

 

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

So I've noticed an interesting point.

On the corporate network I don't want users to talk to each other (client isolation) however enabling this means that windows update peer to peer does not work. To get around this I turned off the client isolation and added my own rules to the user role saying to allow the TCP and UDP ports for Windows update delivery optimization and allow traffic to the gateway. Then after this I put in an any any deny rule to the whole corporate subnet.


Upon testing I put any any permit rule above this and calls worked. Now for the understanding...

Why would an external call from ms teams need to talk to other clients on the same subnet ? Why would this block traffic going both ways on the media part of the call. Not sure why this is required.

Why would an external call from ms teams need to talk to other clients on the same subnet ?

 

Adding the allow all acl (any any any permit) allows all traffic to be cleared on the firewall end. This includes ( but is not limited to ) protocols related to voice such as SIP, RTP etc.  

 

By client isolation do you mean you have used the deny inter-user traffic knob in the VAP profile or have you configured an ACL for it?

 

The calls should work provided all the voice related ports are allowed and are mapped in a higher position than any acls that deny all traffic

 

For Example, the following ACL allows SIP traffic between two users.

 

<Source IP> <Destination IP> svc-sip-tcp permit position 1

 

However if it is mapped in the following way then the voice traffic is denied as the position of the ACL 1 is prioritized.

 

ACL 1

 

<Source IP> <Destination IP> any deny position 1

 

ACL 2

 

<Source IP> <Destination IP> svc-sip-tcp permit position 2

 

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

Ok so narrowed it down by testing this.

 

Add a rule to:

 

allow anything to the corporate wireless subnet on UDP ports 1024 - 65535

 

Now i know that is bascially all available ports but wondering why it needs to access those UDP ports on it's on subnet to make a VoIP call externally?

BTW Our default gateway of this network is a VRRP address on the controller

 

 

What about allowing TCP ports?

This link may give you an idea of all used ports for voice.

https://www.arubanetworks.com/techdocs/ArubaOS_62_Web_Help/Content/ArubaFrameStyles/Voice_Video/Configuring_Voice_and_Vi.htm

Not sure about TCP ports but it works on UDP but i still am none the clearer why I need this rule 

i dont want to allow my clients on the same subnet to communicate over all those ports

Weirdly enough if you just use the check box deny inter user trafifc the teams calls work - so what is so different about doing it myself with an ACL?

An implicit deny all acl which is added at the end of every role is the issue here in your case.

Unless explicitly stated for a port to be permitted, it will be denied. The Acls work from top to bottom.

The implicit deny all acl will be added to every acl you create.

Not sure what exact acls the deny inter user traffic knob uses. But it should allow VoIP.

If you could get the list of protocols and ports used during a VoIP call for Microsoft teams then you could tailor the acls specific to those instead of allowing a wide range of the port's.

They have said it doesn't require access to it's own subnet however I see otherwise

 

Can you do a firewall or acl that allows traffic from a specific Source Port (UDP) ? 

 

Tried to use an extended ACL but it says invalid port

Try to configure a netservice first. Use the below command to do that.

 

(A_RAK)(config) #netservice

 

For example,to create a netservice  use

 

netservice corporate-udp udp <port number>

 

Please refer the AOS 8.5 CLI reference guide (Page 794) for more information on this command.

 

Next use the netservice (corporate-udp in your case) in your ACLs.

 

any <corporate network> corporate-udp permit position 1

 

This will allow all traffic from the specific UDP port to your corporate network.

 

<corporate network> any corporate-udp permit 2

 

This will allow all traffic from your corporate network to any destination through the UDP port.

 

Both these rules are necessary for to and fro communication.

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

 

---

@scottm wrote:
We are having an issue with calls not connecting from our corporate wireless network across multiple sites. It works fine from our guest network. Not sure if it's related to the controller or set up but just wanted to raise a ticket to check if there has been any VoIP related issues with version 8.4.0.3 when running an MM environment.

Also wanted to check if deep packet inspection causes any problems . We have had this enabled all along so don't think this is the problem unless there has been a change in code version of how this operates.

The two ssids are on the same controller pushed to all APs. Only difference is corporate authentication is done via 802.1x certificate via Microsoft NPS but users can connect and browse internet fine

Calls showing connected in the service dashboard but all showing length of around one minute and users calls are silent when answered. Not sure why this would work from one SSID but not another . Anyone heard of this or know how best to troubleshoot?

Thanks

---

In a practical sense, blocking all traffic between users and then attempting to make exceptions does not work well.  If two users are in the same subnet and they need to ARP for each other’s IP address to talk to each other, “deny-inter-user-bridging” will simply not work, period.  If these user devices are managed, you would have a much better control using the built in firewall on hosts, OR, allowing all needed inter-user protocols with an ACL and then denying any other traffic to that subnet.  Enabling the knob to deny traffic and then selectively trying to selectively enable protocols will not work based on what you seem to be asking.

 

In a word, we have seen customers try to get very granular with allowing and blocking traffic via many ACLs for authenticated users, but run into many issues when they constantly have to add/remove and maintain the application ACLs.  It becomes a real administrative burden in the long run.

Hi Colin,

Agreed maybe we need to look at the way we do stuff as it is becoming a bit granular.

I was just trying to understand why this deny inter user traffic would allow the calls to go through on our guest network when checked.

However on corporate when we turn this feature off and insert our own block through ACLs to allow ports 7680 (WUDO - TCP / UDP) it allows those ports fine, blocks everything else but in turn the teams VoIP calls have no audio.  Just seems a strange one and was trying to work out the differences.

 

Can I just ask as well the difference on the ACLS between a deny and a reject?

 

Thanks

Update on findings it would appear the return packet coming back was being blocked due to the desination on the packet being the corporate subnet (local IP) - which the ACL in turn would block - I believe this is why the inter user traffic option does not block it as it is only being connections between clients on the same subnet.

Deny inter user traffic would not allow a client to send traffic directly to another client in the user table.  If one user is sending traffic to a server and a server is then sending that traffic to another user, we have no way of knowing that, and it will not be blocked.