Universal Call Connector over VPN

Unanswered Question
Mar 9th, 2009
User Badges:

I'm trying to get the UCC 1.5 to work at the remote end of a VPN (871 -> UC520, with one 7941 phone, which works perfectly).  When I attempt to verify registration, etc., it can ping and find the CME router, but then times out and returns a message that it cannot read the expected reply.  I expect that there is either a port-forwarding or ACL issue in play here.  Can anyone point me in the right direction to get this to work?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven DiStefano Tue, 03/10/2009 - 14:53
User Badges:
  • Blue, 1500 points or more

Hello.

I have a SR520 remote Teleworker and a 871W ISR Teleworker set up on my UC520 and also have UCC 1.5 Personal CLient on my PC.

When I saw you post I figured I would try it and give you the answer real fast ;-)


But I am seeing the same thing you are seeing.  If I connect the laptop with UCC on the UC500 LAN, I can control phones on the system and it works great, but If i connect the same PC to one of the teleworker subnets, launch UCC and use the CME TSP wizard to select a phone,  I see the SKINNY messages (port 2000) going to the CME on the host UC500 and see the one reply (RegisterTokenAck for example) but the Register Message itself gets retransmitted again and again and finally I see

"Cannot read expected Acknowledgment message" on the UCC CME Wizard GUI.


I have opened a dialog with the TME and Developers for the product and will get an answer, which I will be happy to share with the community ASAP.



Steve

SE for Small Business Channel in the US

Steven DiStefano Tue, 03/17/2009 - 09:48
User Badges:
  • Blue, 1500 points or more

Looks like there could be some issues with operation across NAT, which is the configuration for SBCS Remote teleworker.

However, no firm words back yet and the BU is investigating.

Steven DiStefano Mon, 03/30/2009 - 07:58
User Badges:
  • Blue, 1500 points or more

It looks like this is an unsupported capability.

I have the BU looking at it, but looks like this cant work across a NAT.

aapexisinc Wed, 04/01/2009 - 09:35
User Badges:

I've tracked where the problem occurs using a packet sniffer (wireshark).  Printouts are attached; the process seems to have no trouble with the VPN until it gets to the RegisterMessage packet (packet 10).  At that point, the Ack never comes back from the UC520, as it does when run locally (packet 11).  Hope this helps isolate the problem.

Attachment: 
aapexisinc Thu, 04/09/2009 - 11:53
User Badges:

Did the files I uploaded help at all?  This problem is holding up an installation, so it's very important to get a resolution.

Steven DiStefano Tue, 04/14/2009 - 07:07
User Badges:
  • Blue, 1500 points or more

The Product Manager for UCC (John Vickroy) informed me that this would not work across a NAT environment, which is the environment we have for remote teleworker.  I am sorry to report that according to the Business Unit, this will not work as we have tried (both you and I captured the same trace data and I also shared it with the internal team).

aapexisinc Tue, 04/14/2009 - 09:33
User Badges:

This is not good news.  I want to point out that the FAQs for the UCC claim that it will work at a remote site.  Did they say what the issue is, and why they cannot fix it?


Also, I wanted to try a workaround by running the UCC through a Windows VPN client (since the 871 is allowing split-tunnelling, or even by running the PC apart from the 871), but now the UCC apparently cannot access its license file on startup when the VPN client is running!  This used to work in an older version of UCC; I personally was running the UCC over the VPN client to control a soft phone.  Help!

Steven DiStefano Tue, 04/14/2009 - 10:03
User Badges:
  • Blue, 1500 points or more

I was trying to avoid OOB CLI, so perhaps in the default SBCS with CCA mode of operation, it wont work.

Thanks for pointing this out Steve.  I have not tried that NEM method.....

aapexisinc Tue, 04/14/2009 - 10:39
User Badges:

I'm not sure I fully understand NEM, but I was under the impression that it doesn't permit split-tunnelling at the client; all internet traffic is routed through the EZvpn server site.  Is this correct?

aapexisinc Wed, 04/15/2009 - 12:58
User Badges:

I tried simply changing the EZvpn connecion mode from client to network-extension in the 871 and suddenly everything worked.  I can't recall what the CCA default was, since I know I fiddled with things for other reasons, so I may have inadvertantly changed it.  In any event, thanks for your help!

John Platts Wed, 09/23/2009 - 06:29
User Badges:
  • Silver, 250 points or more

I have been able to use a single CallConnector Server with site-to-site VPNs, even with multiple UC520 units.


Here is one of the ways to do site-to-site VPNs, and I know that this configuration works on the UC500 and ISR platforms:

crypto keyring AtoB-Keyring

pre-shared-key address key

!

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!

crypto isakmp profile AtoB-KeyProfile
   keyring AtoB-Keyring
   match identity address 255.255.255.255

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!

crypto ipsec profile AtoB-Tunnel
set transform-set ESP-3DES-SHA
set isakmp-profile AtoB-KeyProfile
!
interface Tunnel0

description Site A to Site B tunnel
ip unnumbered BVI1
tunnel source FastEthernet0/0
tunnel destination
tunnel mode ipsec ipv4
tunnel protection ipsec profile AtoB-Tunnel

!

ip route Tunnel0


The following constraints apply to this setup:

  • Subnets connected through the VPN connection must be unique across all of the sites
  • You need to expose Data and Voice subnets for CallConnector and VPIM functionality
  • Difficult to set up without static IP addresses at the sites using site-to-site VPNs

Actions

This Discussion