A couple of things spring to mind

1) Is the phone programmed correctly i.e. is it getting teh call server address and so on?
2) Is H323 inspection turned off on the ASA?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

Hi mattKnight,
Thanks for your reply.

1) Before the current phone left the office, we tested it through a CradlePoint and it logged in and worked just fine, so I believe that it is programmed correctly.
2) No, it is turned on. Both "H.323 H.225" and "H.323 RAS" are turned on (I'm not sure which one counts here - or both). They are both using the default map.

One more thing I just noticed. Under IP ENDPOINT DATA, Native NAT Address shows the IP address assigned by the ASA. Looking at another station that is working fine through the VPN, the same setting shows as "not applicable".

Quote:

2) No, it is turned on. Both "H.323 H.225" and "H.323 RAS" are turned on (I'm not sure which one counts here - or both). They are both using the default map

I strongly recommend that you disable it; both options are relevant. Avaya's implementation of H323 (extending the protocol) doesn't match Cisco's ideas of what H.323 should look like and I have had problems with inspection turned on on Cisco. However, having re-read your initial post, I think the ASA is common to all handsets, so this is unlikely to be the issue.

What device is creating the VPN at the remote end?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

Thanks again for your help, Matt!

For all of our users, the handset is creating the VPN at the remote end.

So the phones are setup as VPN phones.
I have seen an issue with Avaya VPN phones not working when the home equipment hands out 10.x.x.x addressing. I would check to see what IP address the home network is giving out. you may need to have them change that to 192.168.x.x

Thanks DAVIDPAYNE,
Good thought, but the user's local network uses a 192.168.X.X scheme.

We have now ordered a FortiGate 30E to configure and send to the user. Hopefully that will allow the phone to work.

Hard to get a PCAP from a phone like that, but syslog can be used. What i've seen is some firewalls doing the NAT thing and if it were a site-to-site VPN and you could get a PCAP unencrypted of what's up on the phone, you might see a signaling packet telling the phone to send the audio the public IP of the firewall at the main office.

Are you running checkpoint?

kyle555,
Checkpoint VPN? No, Cisco.

Verify the end user is not on 192.168.2.x. or 192.168.11.x
Since this is only one phone check what type of Router/Firewall they are using and see what it supports for ALG parameters.

Thanks jimbojimbo,
They are not using either subnet that you mentioned. Although, I did find out that the subnet they are using is the same subnet as our VoIP system in the office. I wonder if that could be an issue.

They have an eero router from RCN. I researched a bit online and have seen mention that eero routers do not have SIP ALG turned on, and it cannot be turned on.

Hi, I also use many ASA and Avaya phones but no problem.
1. Please provide to us crypto map ACL and filter
2. IP address of your phone
3. IP address your CM and G450/430 or other media gateway

ISSUE RESOLVED:
This issue has now come up twice. It turns out that the local subnet of the user's eero router was in conflict with our local subnets here at the office. Both users had an eero router with RCN Internet service.

As I mentioned in a comment above regarding the first case, we discovered that the user's local eero subnet was the same subnet as our VoIP subnet in the office. In the second case, the subnet was not the same as the VoIP subnet, but was the same as another subnet in our network. I don't know why it was causing an issue in the second case, as it should not have been attempting to reach the switch and thinking that the subnet was local.

In any event, the symptoms were the same in both cases. The phone would connect to the Cisco VPN and would then successfully log into the extension. The user would get no dial tone and could not make or receive calls. The phone may then just show "Connecting..." on the screen and the only thing that you can do to affect anything is restart the phone.

SOLUTION
You will need to ask the user for permission to log into their account to control the eero router. You cannot simply enter the default gateway address in a browser at their location to access the eero router's settings. You will need to install the eero app on a mobile device to access it. This will work from a remote location - I have done it from the office both times. Note that these steps are from memory, so it may be slightly different, but it's close:

1. In the eero app, tap Log In
2. Enter the email address or cell phone number that is associated with the user's account.
3. Enter the code that was sent to the user's phone or email. You should then be logged into the user's eero router.
4. Tap Advanced
5. Tap Network Settings
6. Tap DHCP & NAT
7. Tap Static IP. You will get three options: 192.168.0.0, 10.0.0.0, and 172.16.0.0
8. Choose one the other options that would not conflict with any of your local subnets. I have use 172.16.0.0 since we do not use anything in that range.
9. Tap Set. Notify the user that their router will restart and they will lose connectivity. Any of their devices that do not automatically reconnect will need to be restarted.
10. Confirm the message that the router will restart. The router will restart fairly quickly (~30 seconds).
11. Restart the phone. It should work normally.

In the second case it was probably using the routes advertised in your internal network to send the call to the local subnet where it would just get dropped if there was nothing able to do H.323 or SIP (whichever you are using) at that IP.

Thanks for the update and detailed solution information. Definitely star worthy.

Thanks. That makes sense. I kept thinking the problem was happening on their end, but it never occurred to me that it was getting caught up on our end because of their end.