Cisco IP Communicator

Unanswered Question

I have a Cisco UC540 setup with a couple SIP trunks. The phones on the LAN work fine. I can make and receive calls without a problem. I am trying to get the Cisco IP Communicator to work. Right now I am just testing the software on the internal LAN. When I start it up it just sits there saying that it is registering and it never fully registers. I set the TFTP server address to the LAN IP address of the UC540 in the IP Communicator.

I am not sure if it matters but I am not using this device as the gateway for the network. I have a Cisco Pix firewall that is the gateway device for the network. I have 14 static IP addresses so both the WAN interface of the UC540 and the Public interface of my Pix are connected directly to the internet. I didn't want the UC540 routing through the Pix since I thought that might cause a performance problem. I set the TFTP address in the IP Communicator to the IP address of the LAN interface on the UC540.

Any help would be appreciated.


Thanks

Neal

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven Smith Thu, 03/25/2010 - 07:57

The problem is that you dont likely have routes on your PIX pointing to the UC500 to access the Voice and CUE subnets.  A quick and easy change, would be to make the default GW on the computer be the Data LAN IP adddress of the UC500.  If that works, add the routes into your PIX.  You will need them if you are going to VPN into the PIX go use the UC500 with a CIPC client.

I kind of thought that might be the issue Steven. I had previously added a route to the VoIP subnet on the Pix and I am able to ping it fine from my LAN. For some reason, even when I add a static route to the CUE subnet on the Pix, it doesn't respond to pings. If I add a static route on my PC I can ping the CUE fine. Even though I had these routes added the CIPC phone still doesn't register. I did as you suggested and changed the gateway, the phone registered instantly whether I set the IP address of the TFTP server to the VoIP LAN gateway or the CUE address.

The question now comes, if I can ping these addresses from my computer when I change the gateway back, why won't the phone register with it. I still need the gateway for the network to be the Pix since that is the firewall and the VPN terminates there. Is there an access-list setting or something that would block this? Once I get it working from the LAN I will want to test it through the VPN which terminates with the Pix as well but that will involve routing entries on the UC540 to tell it how to get back to the VPN subnet.

Any ideas would be really appreciated.

Thanks

Neal

Steven Smith Thu, 03/25/2010 - 12:19

It could be an ACL, but lets take this one setup at a time.  Make the default GW on the computer you are testing with be the UC500.  That way we can tell if it is a registration problem.  If it registers, then we should look at ACL issues.

Can you verify that the phone and mac address has been added to the system?

OK, I did a bit more testing and I think I have a better idea of the issue. If I change my default gateway to the UC500, the registration works fine. I then tested adding a static route on my computer to point to the VoIP subnet. I already have this route on the Pix which is why I can ping the subnet. When I added the route on my PC, the softphone registered fine.

It looks like the issue lies with the routing through the Pix. I assume what is happening is that when I try to connect to the UC500, traffic obviously goes to the Pix first since it is the default gateway. The traffic then gets routed back through the inside interface to the UC500. For some reason, forwarding traffic directly to the UC500 from my PC works fine but routing it through the Pix doesn't. There is no inside access list on the Pix so it shouldn't be being blocked there.

I am open to any suggestions if anyone has any Pix firewall experience but this seems to be out of the scope of this initial problem.


Thanks


Neal

Thanks for all your help guys, I think I have figured out how to get this to work. I figured I would post the solution here so that it might benefit anyone else that runs into this problem at a later time.

Initially I was trying to get the CIPC to work internally in my network. This was mainly for testing since I probably won't ever use it here. The issue I figured out is, even though I added routes to the Pix and was able to ping the UC500, traffic didn't flow to it. There is a security feature in the Pix firewalls that prevents traffic from entering and leaving the same interface. They are designed as firewalls and not routers so by default, this is blocked. I knew this already and on the newer versions of the OS there is a command to disable this functionality which I had enabled. Before doing that I couldn't even ping the UC500. The issue now was with traffic flow. When I was directing traffic to the UC500 it was going to the Pix and forwarding to the UC which was fine. The issue was that the UC500 would redirect the traffic directly back to the computer since it knew where that subnet was, not through the Pix. That would break the traffic flow and it wouldn't work.

Unfortunately I don't think there is a way around this so I set an option 249 in the DHCP server on my LAN. Option 249 includes static routes with the DHCP messages. I added the static route to the VoIP VLAN and then everything was working fine. Now my computer directly goes to the UC500 when trying to connect to that subnet. That works fine.

That isn't the main issue since I want to be able to use the CIPC through my Cisco VPN. My VPN is setup to terminate at the Pix as well. This fix was a little easier. I have split tunneling enabled for the VPN traffic. I enabled split tunneling for the traffic that was going between the VPN subnet and the UC500 VoIP subnet. Previously I just had it enabled for traffic between the LAN and VPN. Once I enabled it for the other traffic, the CIPC registered in seconds and seems to work fine.

I hope this helps someone else and thanks for your help.

Neal

Actions

This Discussion