Cisco 8831 wont connect via ASA

[Brandon Feemster]

I am trying to connect an 8831 conference phone in one of our remote locations via our ASA but it wont register. I have 8841's and 8811's working just fine in this same location. Does the 8831 not support ASA/VPN connections?

[Slavik Bialik]

Just use the capture wizard in order to capture the traffic on your ingress and egress interfaces on your ASA, and see if the SIP REGISTER message is coming from the phone. Also, try to capture the traffic locally in the remote site, with a port mirroring on a switch for example, and see if the phone triggers a registration towards the CUCM. If it does, but you don't see it in your Ingress interface of your ASA, it is probably a MTU issue in the remote site. Unless you see it in the ingress interface, but you don't see it in the egress interface so it may happen as a result of a MTU on your ASA, or if you do some strange inspect rules on SIP that blocks those messages from some reason. I had a client that is using Checkpoint as a Firewall and he limited SCCP messages to 1000 bytes, and some registration messages were blocked from time to time as a result of that, and it lead to registration loss in lots of devices, so it makes we wander if you have something like that, too.

Also, run a capture on your CUCM and see if the REGISTER message is arriving the CUCM at all, and if so, what the CUCM is returning to the IP.

If you want, you can share the capture files with us and we can try and help you to diagnose them. Because I think your issue is networking.

[Brandon Feemster]

Thanks for your reply Slavik, I'm going to try what you suggested. Before I do...do you happen to know if the 8831 conference phone is capable of making a vpn connection via an ASA?

[Slavik Bialik]

Can't say for sure, but on the other hand... why not? :)

If I understand correctly you set a Site-to-Site VPN connection, from a router / firewall on the remote site to the main site where the CUCM resides. 

Now, usually when a traffic is going through a VPN it is adding an extra header to the payload of the packets, which makes the packet size to grow in 50-120 bytes at least.

That's why I think you have a MTU problem. Maybe the conference phone (8831) is sending bigger REGISTER & INVITE messages then the other phones you have in the remote sites, which is logical in some cases + I read in some posts about people that are asking why device type X has bigger messages then device type Y. Again, you can easily capture this on your Firewall / Switches.

Check the maximum MTU size that is configured for your VPN... and out of curiosity, what is the mss adjust value configured in the context of your firewall "sysopt connection tcpmss ???".

Anyway, we'll know more after you'll capture the traffic on all ends. But my feeling is that the traffic is dropping when trying to go out through the VPN connection.

[abyewondimu]

I have a similar issue as below

History:

The  Cisco - 8831 has to go through a VPN tunne before it gets to the CUCM to register.All other phones register not a problem. It gets its ip and configuration file no problem. Only problem is registering. The wireshark packet capture shows the phone is send MTU 1514 with df 1 (not to fragment). This phone register when it is placed in another location where there is no vpn tunnel between the phone and CUCM. Some of the Cisco phones you can change the df bit to 0 or 1 (Under Product specific Configuration layout) but not in case of thee 8831. So the work around was to creat an access list and force the df bit to 0 before teh ipsec process happen.

1- The phone was sending the traffic with DF bit as 1 to avoid fragmentation.
2- We tested for possible fragmentation issues, from the device closest to the phone we tested the ping with a load and df bit set. Fragmentation was required and hence because of point 1 it do not worked.
3- Based on the document:
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/82444-fragmentation.html

a. Configured the command “crypto ipsec df-bit clear” but the behavior did not improve.
b. Configured then the route-map option for setting df bit to 0 on the interface before the ipsec process happens.

Created the ACL:
Router (config) # access-list 150 permit tcp any any

Configured the Route map:
Router (config) # route-map VPN_DF permit 10

Router (config-route-map) # match ip address 150

Router (config-route-map) # set ip df 0

Router (config-route-map) # exit

Applied the Route map on the interface:
Router (config) # interface GigabitEthernet0/0/0

Router (config-if) # ip policy router-map VPN_DF

And then the phone register.