cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9319
Views
0
Helpful
57
Replies

SPA525G SSL VPN Stability Issues

mgallant
Level 1
Level 1

I just upgraded our UC520/32U to 8.1.0 and bought a few SPA525G's to use as our teleworker phones.  I've got the SSL piece up and running and the phones come up just as they should in the remote locations.  Everything seems to be working just fine.  BUT, the remote phones seem to be acting "flakey" every so often.  Here are some issues I've run into this week:

  • Calls dropping....phone locks...phone does the equivalent of a "restart" and then the phone is back to normal
  • Sometimes, if a phone is power cycled, it will constantly reboot and will never connect to the UC520.  I've played with this a little and have found that if I have the user unplug the phone for 5 minutes...and during that time I clear all the SSL tunnels using that username...and have them power it back up, that it will often work.  Pretty flakey.
  • Call quality is often horrible.  I'm running G729 on all phones to conserve bandwidth.  Most of the time the calls are OK, but I get complaints on call quality.  We used to be running IPSEC tunnels to all the remote users and had 7965's as remote phones and they worked perfectly, so I'm inclined to believe that it's NOT a bandwidth issue.

Has only had a lot of experience with these phones using the SSL VPN client?  I can alway fall back to doing IPSEC tunnels for most of the users, but that just doesn't seem smart.

Last piece of info...phones are running the load that came with 8.1.0 which is 7.4.6.

Any help will be greatly appreciated!

Thanks in advance!!

Matt

57 Replies 57

They are just ezvpn tunnels from the UC520 to my 871W's at the remote locations.

Found a solution to the soft button keys not showing up on the 525g's. The issue is linked to the localization files. Here's a link to another thread that talks about the solution. 

https://supportforums.cisco.com/message/3257891#3257891

I updated our config.  I didn't see any change on 7.4.6 but I'm going to try 7.4.7 and see how that pans out.  I can't see this having any affect on the stability of the VPN, so I'm not even going to try that...

So I upgraded to 7.4.7 after changing the following two lines under "telephony-service" from:

user-locale U5 load CME-locale-en_US-English-8.1.2.1.tar
network-locale U5

to

user-locale US load CME-locale-en_US-English-8.1.2.1.tar
  network-locale US

The only thing that changed was the "U5" to "US".  I'm not sure if that was a typo in the canned config for 8.1 or what, but updating definitely helped!  7.4.7 seems to be running fine and the button labels show up perfectly now.

One thing to note to the Cisco team...doing an upgrade from 7.4.6 to 7.4.7 over the IPSEC tunnel took maybe 30 seconds to download vs. right at 17 minutes using the SSL VPN client in the 525G.

It looks like in 8.1, the user defined local is defined. This is what the U5 is, since you can setup 1-5. In testing on our lab system, I found that when you set to U5, the files are pulled out of the tar file, when you set to US, the files are deleted and it looks like the phone uses the default US locality in it's firmware.

Glad what I found also fixed your button issues.

jyoopro4ia
Level 1
Level 1

you're not alone.. I dread working with the 525Gs due to it's unreliability based on my past few depl

oyments..  it's hit or miss sometimes.

What types of issues have you run into with the 525G's?  The only problems I've experienced are related to the built-in SSL VPN client.  Are you saying that you've had other issues that are not related to the SSL VPN stuff?

OK I think I've made sort of a breakthrough, hopefully it's not short-lived.

Since I've been tinkering around with multisite manager and VPN setup, I've had to delete the firewall, multisite VPN, and SSL VPN settings so that my configuration changes didn't conflict with CCA.  I noticed now that, when I rebuilt the SSL VPN settings with the new CCA 3.0.1, all my spa525g phones are connecting without a pause or hiccup.  I've also noticed that there's an entry in the "interface GigabitEthernet0/0" section that might have been preventing all this from working properly, and it could've of been the old 8.0.x and/or CCA 2.x to blame.  Here's what it looked like before and after:

!BEFORE

interface GigabitEthernet0/0

description $FW_OUTSIDE$

ip address (wan_IP) (subnet_mask)

ip access-group 104 in  <-----------------------I found this to be the culprit

ip verify unicast reverse-path

ip nat outside

ip inspect SDM_LOW out

ip virtual-reassembly in

load-interval 30

duplex auto

speed auto

crypto map multisite

!

!AFTER

interface GigabitEthernet0/0
ip address (wan_IP) (subnet_mask)

ip nat outside
ip virtual-reassembly in
load-interval 30
duplex auto
speed auto
crypto map multisite
!

Now, keep in mind that I deleted the " ip access-group 104 in" entry BEFORE I rebuilt the firewall/VPN/SSLVPN config.  So, hopefully everything will be working from now on and I can move on with my life.

:-)

Renato

It may help you out, but I wouldn't count on it. I had my ACL configured properly and I was able to connect, but I still had plenty of problems... dropped calls, horrible call quality, tunnel drop and reconnect...

I had the same issues with a UC540 that was attached to a Comcast Modem (12Mb down/5Mbup) which is the gateway to the Internet.  We have three 525G (1&2)  teleworkers that were having problems.  What I found is that the auto negotiated Ethernet link speed between the UC540 and Comcast Modem was off.  I configured both devices to 100Full.  (I had to reboot the UC540 to take affect).  Connection and voice quality significantly improved.  They still get some quality issues if the local Internet is being used heavily.

The other thing I've done in my own remote location and for the three user I described above is configure device QoS on their local access router (Linksys in most cases) to give high priority to the Ethernet Mac address of the 525G phone.  On the Linksys web GUI it's under Application & Gaming -> QoS.

Recently, in the last week, my own remote 525G phone has been spontaneously rebooting which I’m using it.  I haven’t found this problem yet, but will let you know what if anything I find.

I’m also disappointed that Cisco hasn’t given any visible attention to these problems.  When calling SBSC for the first problem I mentioned above (as I spent about three days trying to figure out the problem) they said they haven’t seen any teleworker voice quality problems with the 525G’s.   Teleworker 525G is one of the key elements of a borderless network and I’d like to see Cisco treat these problems as a class-action CAP case.

Joe Gadell
Level 1
Level 1

Are any of you running the 525Gs over WiFi at your remote locations?  We just deployed one with an SRP540W router.  Phone is using WiFi and running SSL-VPN.  So far, so good.  I haven't had time for heavy testing yet.  I was disappointed to read WiFi is only supported with a Cisco AP, but I guess that makes sense.  I have QOS enabled on the voice VLAN and it's prioritizing well according to the stats on the SRP540W.

Thanks.

Nope...my remotes are all hardwired. What version are you running on your UC500 and the phones?

I have a user that runs it, so far it's doing good. Occasionally he gets quality issues but most of the time it's good.  One of the things you can do to really test the phone out is by doing conference calls.  That seemed to be the problem we had when we first started setting up these phones a few months ago.  During a one-to-one call it was fine, but as soon as you go in a conference call, the quality turns to crap and it's not even bearable.

I haven't even tried conferencing...it was bad enough on single calls!!

Matt,

Are you sure it's not a bandwidth or firewall issue?  Have you tried putting the SSL VPN phone straight out to the Internet and not behind a firewall?  One of our issues was that we are using this WAN router that aggregates multiple WAN links and use them for load balancing. Once I put the UC outside of that device, the spa525g phones worked much better.