cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1321
Views
0
Helpful
3
Replies

UC560 - IP Communicator Connectivity over the VPN

smunzani
Level 1
Level 1

Hi,

I have a general question around how UC560 operates with IP communicator. Below is my sanitized network diagram of the UC system.

UC560 Connectivity.png

Key Pointers:

1. I am not routing the phone subnet(10.55.32.0) to my firewall or internal LAN because there is no reason for people to get to that subnet. If I allow, there is a potential some day a trojan may launch DoS against phones.

2. I am doing SSL VPN on UC560 for the SPA525G2 phones only. No data VPN terminated there due to scalability challenges.

3. Data VPN terminates on ASA5510.

Requirements:

1. When an user is connected to the ASA5510 via VPN, he/she needs to access all the internal data VLANs + IP communicator has to work as well as IMAP profile in outlook for the Unified Messaging.

2. Let users access IMAP emails without VPN connection via port forwarding the CUE IP and IMAP port.

Challenges:

Public IP shortage. I am trying to avoid burning too many public IPs if I can get away.

Questions:

1. What's my best approach? Do I have to route 10.55.32.0/24 network to ASA5510 for people with IP communicator or can I get away with LAN interface(10.55.11.10)?

2. What's best approach for IP communicator deployment? The people who would use IP communicator also has office and a desk. They would use it when they are not in office. Is primary shared line for office phone and IPC better approach or Extension Mobility?

Thanks in advance,

Sam

1 Accepted Solution

Accepted Solutions

Hello Sam,

1. About question one it will be against your first key pointer if you do it this way, because you will need to enable communication between the voice vlan, cue and data network. Maybe if you do not want to enable this communication you may need to create another subnet for VPN users who will be able to reach the voice and cue vlan.

2. Both approaches could be used. IMHO shared extensions approach seems more natural to cme and less complicated for users.

Best regards,

Alex

View solution in original post

3 Replies 3

Hello Sam,

1. About question one it will be against your first key pointer if you do it this way, because you will need to enable communication between the voice vlan, cue and data network. Maybe if you do not want to enable this communication you may need to create another subnet for VPN users who will be able to reach the voice and cue vlan.

2. Both approaches could be used. IMHO shared extensions approach seems more natural to cme and less complicated for users.

Best regards,

Alex

Hi Alexander,

Instead of routing whole 10.55.32 subnet, I simply routed the 10.55.32.1 IP from internal network and ASA to get this going. For the softphone, I went with shared line to keep it simple.

Thanks,

Sam

Hello Sam,

Thank you for the feedback and the good rating. 

Best regards,

Alex

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: