Has anyone got a vpn to work for teleworker on uc320?

[placroix]

Team,

I have a customer with 2 sites with 3 phones each. Uc320 is in site A I want phones in site b to be able to register. Has anyone gotten this to work with the UC320??

If so What was your solution?

We really need SSL VPN on this box!

Thanks

Paul

[David Hornstein]

Have tried playing around with back to back VPN's via RV220w and SA500 , but unlike the older SPA9000 I cannot get one UC320W to register with another Uc320W.

Maybe someone knows the magic.

I did hear that a Teleworker solution is in the pipeline/roadmap. 

[Christopher Edgeworth]

Hi,

The original request was around a teleworker solution.  To really support a teleworker solution and make it easy to implement, maintain, and configure will take some design work.  This is one of the front runner features being considered for the next feature releases.

David,

If you want to make 2 UC320W communication over SIP trunks, you simply set them to not register.  The proxy address is the remote UC320W WAN IP.  No NAT between them. This will work for demos etc, but is not the optimal solution because the dialplan gets ugly real fast.

Chris

[David Trad]

Hi Paul,

For remote Teleworkers, you can use the 800 series routers such as the 857/877 and create a VPN tunnel between them, then make sure that the UC-320W's IP's are authorized in the ACL, and the remote phone should register without a problem

I am going to try this with the SRP-527W Routers when I get the chance, but these sort of LAB/Tests are not easy to get up and going as two people need to be involved and free time set aside in our personal hours. However since the SRP-527W supports IPSEC, and it being GUI based id imagine it shouldn't be a problem to do... But alas it is Cisco and in saying that I always find myself in trouble

IT would be good once they release UC-320 - to - UC-320 Registration for like multi-site deployment scenarios, this would then allow the UC-320 to compete with the likes of the smaller Asterisk embedded systems out on the market, they do it quite well and those systems work quite well, they either use IAX or SIP to communicate with each other.

Cheers,

David.

[marcmeeks]

Nice post David, so the only way currently for teleworkers is vpn tunnel to uc320. We are looking at hosting a uc320 at our ddatacenter for a client that is dispersing there 7 person staff between 3 locations. I'm fairly new to the UC line of products and initially thought the uc320 had support for teleworkers. I know that the UC500 series does support them. Would you recommend going with the 320 and vpn or the 500 series and it's remote teleworker capabilities.

Thank you,

Mark

[David Trad]

Hi Mark,

The UC-320W Does not have the same capabilities as the UC-500 series, if remote workers is an important part of the project and can be considered "Mission Critical" which it looks as though this could be the case, then we have to be honest with ourselves and say that the UC-320W is not the right solution.

Been experiencing this a lot lately, seeing the a Cisco solution being sold into the wrong environment for the sake of a sale (And I am a Cisco fan boy ), do not fall into that trap because no matter how much support Cisco will give you for the product and deployment of it, if it is the wrong solution, you will end up not being able to show face to the client and will be plagued with continued problems.

Look at the UC-500 and the SPA-525G2 phones using SSL VPN back to the UC-540W in the Data Center, but I caution you, this is not without its own problems, the SPA phones still seem to have some fundamental issues and a fair bit of ironing out but the solution is workable, just make sure you set the customers expectations right from the word go, do not promise the earth because they wont get it

FYI: Using the 800 series router and creating a VPN tunnel, whilst it can work it has a "LOT" or troubles and is not stable, I managed to get it to stay up for about an hour, and then after that it would drop out or not even connect, something tells me it is just not meant to be done this way, so I am going to leave it alone until the Dev team come up with an "on-systems" solution that required no non-trivial way of achieving it.

Cheers,

David.