Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VPN Phones -- Registration Rejection

Status
Not open for further replies.

mizuno

Technical User
Mar 29, 2006
38
0
0
GB
We currently provision our h.323 phones with vpn firmware. While these do work for the most part they are difficult to manage. We suddenly have issues with multiple remote users having no audio once connected and some that sit and discover. The vpn tunnel establishes with no problem and there are no firewalls once inside. In running a packet capture we see the call server rejecting registration with an unknown error. In searching various threads all it says is to contact your Avaya administrator. Has anyone seen this before? This is coming from the PE of the duplex call servers.
 
What registration errors do you see from CM ??

If the stage 1 & 2 VPN is passed generally this is down to h.232 packet inspection on the firewall , if you run a "list trace ras ip-address xxx.xxx.xxx.xxx/ or ip-stations xxxxx" what do you see on the ras event in CM , also the web interface ip events log is useful in troubleshooting.

The issue is even with the tunnel built and running a wireshark on a PC plugged into the phones switch port you will not see tunnel traffic.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.
 
We have well over 1000 9620 & 9621L setup as VPN phone at agents homes. I see this type of issue most often when the end user has the POS modem/gateway the IPS provides them. They will work fine one day, and then the next they get VPH tunnel failuer or discover. Normal if I can get the user to but that gatway into bridge mode, and they get a cheep router. issue goes away. The ISP can push changes out to those gatway when every. and they are blocking traffic back from CM to the phone, etc.
 
Would have to run those traces. I checked the ip events log and I'm getting nothing for different dates. Is there something else in that page that needs to be flagged?
 
Typically, any connectivity issues were related to the cert expiring, but this is def not a cert issue.
 
So the ip events log from web interface "should" match to greater extent what you see on the list trace ras events ,the difference being on the list trace ras you will see the request ,authentication and acceptance or rejection in a sequence of events , however when a problem exists you may see random stuff like unregistration when no registration has actually occurred.

You can run a TCP dump from the NIC interface if you are a system platform based CM , this can then be analysed in wireshark , just be sure to turn it off the you have finished tracing.Below is an example of how to run a tcp dump(in your case the remote backup step would be replaced by attempting to register the phone and the remote_server would be the ip address of the handset)

a trace can be gathered by SSH'ing into domain0 and "su - root" then execute command as follows where remote_server is the IP or the SFTP server:
tethereal -s 10000 host remote_server -i eth0 -w /home/admin/dump.dmp

Once the above is running, perform an attempted remote backup from the cdom gui. Once failed you can CTRL+C the above trace, then "chown admin home/admin/dump.dmp" and connect to dom0 using something like WinSCP to retirieve the trace for analysis in Wireshark.

I do have to say however the only issues i have encountered is with checkpoint firewalls , they are just nasty.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.
 
@mizuno -- are you sure your certs aren't expired on the phone or even the edge router? We've had it happen on each end and it was only seen in the logs of the router. Also, our external IP once changed (since we don't use a dns name) and the tunnel didn't establish.
 
No-No output shows up in my IP event log, even if I put in just 2016. For the most part these phones are all within a year of being provisioned. We use 2 year certificates and some phones do register, but have no audio. Others fail to discover the Call Server IP. All happened on the same day, as well. The only common thing I see is the problem phones were off. The phones that have been online are fine, but I'm assuming if they reboot they will have the same issue. These are all 9630G phones.
 
He is saying his tunnel establishes so the certs will not be an issue.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.
 
Definitely not a certificate issue. All of the in-office phones are registered fine, and to the PE. We also have a handful of folks using Aruba RAP's with the phone and those are fine as well. Those are not flashed with VPN firmware, so this is only impacting VPN endpoints. I was concerned I was going to have to do an Interchange as a trouble step, but I don't see a need to do that.
 
Have you tried a mute clear on the sets , this could be something like GARP if the servers have interchanged since first registration

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.
 
If I run the clear procedure it wipes the phone and it needs to be re-provisioned. I'll see how I get on with those traces you referenced.
 
May not matter but have you tried upgrading the phones to the latest firmware?
 
We fight this issue every day. VPN Tunnel Failure and phone in Discover mode.
99% of the time the issue is with the end user home network. And 99% of the time the end user has gotten the modem/router/Gateway (single device) the ISP provided them. The VPN phone use an IPsec VPN connection, our PC builds us Cisco Anyconnect. The PC connect fine, we just have this issue on the phones. Of the 1000 – 1800 VPN phone we have out, if the user has their own modem and a separate router we almost never have these issue. Also there is a now issue if the home router is handing out 10.x.x.x address and getting discover on the 96xx phones. Make sure the home user router are handing out 192.168.x.x address.

One way audio is another issue. Check to make sure that all of your VPN phone IP address are setup in the correct regions.
 
Is flashing these with SIP FW and coming in via an SBC more reliable than VPN? I don't have an SBC, but would propose it if it helps with management and reliability.
 
Well remote sip phones with SBC or otherwise requires a session manager for the sets to register to , if you already know this apologies for teaching you how to suck eggs , my preference to you would be to get an avaya dev connect document and implement based on the technologies that have been tested, as really if you have home devices trying to act in an business critical environment , it does not matter if you are using SIP, H.323, or the force..... the weak point is always the homeworkers edge device.

Get that correct and all will work ok , granted that may mean purchasing some dedicated hardware for the homeworkers and a business connection .... but hey if its critical to needs , the amount of time you will spend farting about in man hours implementing and supporting the headache will be minimal ........ the other way forward is to have a true site to home VPN (again dedicated connection preferred ), and simply static the phones and have them act as a normal endpoint , you need to static the devices at each home location (eggs again!) , but i have never had any issues using this method.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.
 
This turned out to be an issue where a BGP statement had to be removed on the VPN router, in case anyone comes across this issue.

Also, our server team is upgrading the internal PKI infrastructure and our VPN phones get their certs from this server. They've indicated this is to support SHA-2 and update the key lengths to 4096. In going through the 46xx.settings file I only see the option for a 2048 key length and there's no mention of any SHA versions. Aside from telling the team this will eventually break all the phones, does anyone have any guidance on how to handle this?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top