Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4513
  • Last Modified:

IP communicator won't register over VPN tunnel

Software:  CallManager Express 8.6, IP Communicator 8.6
Hardware:  ASA 5505, 2801 Router, Catalyst 2960

I can't seem to get an IP Communicator version 8.6 to register over any kind of a VPN tunnel.  On the LAN the IP communicator works fine.  I configured an IPSec VPN client, an SSL vpn client, and even a site-to-site tunnel and tried it from the other end.  Nothing.

After exhaustive research and trial and error I've tried everything.

I've setup ephones with the MAC address of the virtual adapters for the VPN clients.  I connect using a VPN client and switch the network interface accordingly in CIPC.

I've loaded the locale loads in flash and added the appropriate tftp-server commands.

I've created the CNF files in telephony-service and they show up as the .xml file in flash

A debug ephone register for the LAN connection shows the CIPC register and come up.
A debug ephone register when using a VPN client connection shows nothing.

I can ping any IP address on the LAN and Voice vlan including the CME sub-interface at 172.16.2.1.

On the LAN I can telnet to 172.16.2.1 port 2000.  When connected to a VPN I have discovered that I cannot telnet to port 2000 on the router.  Which is what the problem is.  I can't seem to pinpoint what is stopping the ability to telnet to 172.16.2.1 port 2000 across any of the VPN connections.

I have included the ASA and Router config.

Topology is:   ISP Router ---- ASA 5505  ----- 2801 Router ----- 2960 Switch
Firewall-Config.txt
Router-Config.txt
0
jplagens
Asked:
jplagens
  • 17
  • 13
  • 2
1 Solution
 
asavenerCommented:
group-policy IPSecGroupPolicy attributes
 dns-server value 172.16.11.100
 vpn-tunnel-protocol IPSec
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value nonat
 default-domain value domain.local
 address-pools value IPPool

I think that's your problem.  Try these commands:

group-policy IPSecGroupPolicy attributes
split-tunnel-network-list value split-tunnel
0
 
jplagensAuthor Commented:
Thanks.  I just tried making that change and it didn't work.  I have two group policies setup.  One for the IPSec vpn client and one for the SSL vpn client.  The SSL policy is using the split-tunnel ACL.  Neither one works.

I'm thinking it might be something on the router.  I've tried removing the "ip nat inside" and "ip nat outside" commands on the sub-interfaces.  That didn't help.  Maybe it's something in that area?


These are the two group-policies I have setup for the VPN clients:


group-policy SSLClientPolicy internal
group-policy SSLClientPolicy attributes
 dns-server value 172.16.11.100
 vpn-tunnel-protocol svc
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split-tunnel
 default-domain value domain.local
 address-pools value SSLClientPool


group-policy IPSecGroupPolicy internal
group-policy IPSecGroupPolicy attributes
 dns-server value 172.16.11.100
 vpn-tunnel-protocol IPSec
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value nonat
 default-domain value domain.local
 address-pools value IPPool
0
 
asavenerCommented:
Try this:

policy-map global_policy
 class inspection_default
no  inspect skinny
0
New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

 
jplagensAuthor Commented:
That didn't work.  I also tried removing:

inspect sip
inspect h323 h225
0
 
eeRootCommented:
You can try using the ASDM's packet tracer to try and identify what in the firewall's config is stopping the traffic.  Sometimes the packet tracer gives good info, sometimes not.
   You could also try issuing the "telnet 172.16.2.1 port 2000" several times in a row and then check the ASDM log to see if it sees the traffic and shows why it is being blocked.
0
 
jplagensAuthor Commented:
I've never used the ASDM before.  I just installed it.  Where do I find the packet tracer?  Is it the logging at the bottom of the home screen?
0
 
jplagensAuthor Commented:
With the help of YouTube I found the packet tracer wizard and ran it.  I'm not sure of the parameters to run.  I ran these parameters:

Ingress interface: outside
Specify Packet parameters:
Source network: 172.16.100.0 /24  (VPN Client subnet)
Destination network: 172.16.2.0 /24  (Voice VLAN)
Protocol: ip
Egress Interface: inside

Once this was set, I launched the IP Communicator and made sure the adapter was set to the VPN client virtual adapter.

Attached is the output.
ASACapture.txt
0
 
asavenerCommented:
Will the soft phone register when the laptop is on the LAN?
0
 
asavenerCommented:
As a next step in troubleshooting, I suggest that you configure a syslog server and set up logging to it.  Then we can review the log entries to see what's blocking the traffic.

Please set the logging level to debug.
0
 
jplagensAuthor Commented:
The IP Communicator registers without a problem on the LAN.

I'll setup a syslog server.  Any recommendations on a good free one?
0
 
asavenerCommented:
I always use Solarwinds' Kiwi Syslog.
0
 
jplagensAuthor Commented:
I was able to capture some syslog output.

The IP address of the vpnclient is: 172.16.100.1

I connected to the VPN, then started the IP Communicator.
Once that went through a cycle I tried to telnet to 172.16.2.1 port 2000.
Syslog-Monitor.xls
0
 
eeRootCommented:
if the packet tracer isn't showing anything, then you should be able to watch the ASDM log and see if the traffic is being blocked.
0
 
jplagensAuthor Commented:
I took a look at the  ASDM log.  When I try to telnet it only see:

Built inbound TCP connection 98871 for outside:172.16.100.1/51541 (172.16.100.1/51541) to inside:172.16.2.1/2000 (172.16.2.1/2000) (vpnuser)

Teardown TCP connection 98838 for outside:172.16.100.1/51538 to inside:172.16.2.1/2000 duration 0:00:30 bytes 0 SYN Timeout (vpnuser)
0
 
asavenerCommented:
"Aug 16 2012 09:11:40 ASA5505 : %ASA-6-302014: Teardown TCP connection 73680 for outside:172.16.100.1/50376 to inside:172.16.2.1/2000 duration 0:00:30 bytes 0 SYN Timeout (vpnuser)
"

From this, it appears that the router is not replying.  The next step would be to make sure the syn packet is arriving at the router.
0
 
jplagensAuthor Commented:
I tried sending syslog from the router to the syslog server, but am not having any luck.

logging monitor
logging <host>
logging trap 7

I don't see anything.  Any ideas?

Looking at the ASA debugs.  It's considering traffic coming from the vpn client as outside interface traffic.  I'm wondering if I need to open up ports on the router using the NAT overload command?
0
 
asavenerCommented:
You probably need to put on an access list that logs the interesting traffic.

ip access-list extended log_skinny
permit tcp any host 172.16.2.1 eq 2000 log
permit ip any any

int f0/0
ip access-group log_skinny in
0
 
jplagensAuthor Commented:
I added the access list. Actually I looked up what ports the IP Communcator needs and I added those the access list as well.

Cisco website says:

Ports Used by Cisco IP Communicator
IP Communicator is the same as normal IP phone, so it uses these ports:
TFTP (UDP 69)—In order to obtain phone configuration and software
SCCP (TCP 2000)—For skinny (SCCP) signaling
HTTP (TCP 80)—In order to access IP Phone services
RTP (UDP 16384-32768)—For audio

The access list looks like:

ip access-list extended log_skinny
 permit tcp any host 172.16.2.1 eq 2000 log
 permit udp any host 172.16.2.1 eq tftp log
 permit tcp any host 172.16.2.1 eq www log
 permit tcp any host 172.16.2.1 range 16384 32768 log
 permit ip any any


I tried telnetting to port 2000 through the VPN tunnel and all I received on the syslog server was:

%SEC-6-IPACCESSLOGP: list log_skinny permitted tcp 172.16.100.1(54828) -> 172.16.2.1(2000), 1 packet


When I tried the IP Communicator I received the same log message.  It looks like it's permitting it.  Maybe it's the return trip that's stopping it?
0
 
asavenerCommented:
Possibly.  Now make a converse access list:

ip access-list extended log_skinny_out
permit tcp host 172.16.2.1 eq 2000 any
etc.


interface f0/0
ip access-group log_skinny_out out

This will show if the router is replying.
0
 
jplagensAuthor Commented:
I created the new access list.  This is what is in the router now.


interface FastEthernet0/0
 description To ASA 5505
 ip address 10.0.10.2 255.255.255.252
 ip access-group log_skinny in
 ip access-group log_skinny_out out
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto

ip access-list extended log_skinny
 permit tcp any host 172.16.2.1 eq 2000 log
 permit udp any host 172.16.2.1 eq tftp log
 permit tcp any host 172.16.2.1 eq www log
 permit tcp any host 172.16.2.1 range 16384 32768 log
 permit ip any any

ip access-list extended log_skinny_out
 permit tcp any host 172.16.2.1 eq 2000 log
 permit udp any host 172.16.2.1 eq tftp log
 permit tcp any host 172.16.2.1 eq www log
 permit tcp any host 172.16.2.1 range 16384 32768 log
 permit ip any any


When I tried to telnet 172.16.2.1 2000 all that was displayed was:

%SEC-6-IPACCESSLOGP: list log_skinny permitted tcp 172.16.100.1(55024) -> 172.16.2.1(2000), 1 packet
0
 
jplagensAuthor Commented:
I assigned my laptop 10.0.10.1 which is the same IP address as the inside interface of the ASA.  Then I plugged the laptop directly into the router's FastEthernet 0/0 port which is 10.0.10.2.

From this config I am sitting outside of the router and not going through the firewall.  I can telnet into port 2000.
0
 
asavenerCommented:
For it to be a fair test, you need to use one of the VPN addresses assigned by the ASA.

Can you create a DMZ zone with one of those subnets?
0
 
jplagensAuthor Commented:
That sounds like a good test.  Can you assist with the DMZ config?  I'm not sure what to configure to accurately test it.
0
 
asavenerCommented:
You just need to configure an interface that uses the same subnet as the VPN address pool.

Then name it something like "phone_test."  (Don't use DMZ, since the device will auto-assign a security weight.)

Create an access list that allows all traffic and assign it to the "phone_test" interface.

That should be about all you need.
0
 
jplagensAuthor Commented:
I can't seem to get this to work.  I'm getting an error message with trying to name the interface.  I assigned 172.16.100.2 to a laptop and I can't ping the new interface at 172.16.100.1

This is my config for this:

interface vlan3
security-level 100
ip address 172.16.100.1 255.255.255.0


int ethernet 0/2
switchport access vlan 3


access-list phone_acl extended permit tcp any any




ERROR: This license does not allow configuring more than 2 interfaces with nameif and without a "no forward" command on this interface or on 1 interface(s) with nameif already configured.
0
 
asavenerCommented:
OK, that's a license restriction I've never encountered before.

Step 2 (Optional) For the Base license, allow this interface to be the third VLAN by limiting it from initiating contact to one other VLAN using the following command:

hostname(config-if)# no forward interface vlan number


Where number specifies the VLAN ID to which this VLAN interface cannot initiate traffic.

With the Base license, you can only configure a third VLAN if you use this command to limit it.

For example, you have one VLAN assigned to the outside for Internet access, one VLAN assigned to an inside business network, and a third VLAN assigned to your home network. The home network does not need to access the business network, so you can use the no forward interface command on the home VLAN; the business network can access the home network, but the home network cannot access the business network.

If you already have two VLAN interfaces configured with a nameif command, be sure to enter the no forward interface command before the nameif command on the third interface; the adaptive security appliance does not allow three fully functioning VLAN interfaces with the Base license on the ASA 5505 adaptive security appliance.

Note If you upgrade to the Security Plus license, you can remove this command and achieve full functionality for this interface. If you leave this command in place, this interface continues to be limited even after upgrading.

If you're willing to have limited access (no outside-initiated inbound traffic) while testing, you can apply the no forward command to the outside interface, and then finish configuring your new interface.
0
 
jplagensAuthor Commented:
Been out of town awhile.  I've modified the settings usig the no forward command.  This is what I have now:


interface Ethernet0/2
 switchport access vlan 3

interface Vlan3
 no forward interface Vlan2
 nameif phone_test
 security-level 100
 ip address 172.16.100.1 255.255.255.0


access-list phone_acl extended permit tcp any any



I plugged a laptop into port 2 and assigned it 172.16.100.2.  I can ping 172.16.100.1 and that is it.

I thought it might be the route to the 172.16.2.x network.  When I tried to enter a route I get:


Firewall(config)# route inside 172.16.100.0 255.255.255.0 10.0.1.2
ERROR: Cannot add route, connected route exists


A "show route" gives me:

Gateway of last resort is xxx.xx.xxx.34 to network 0.0.0.0

C    xxx.xx.xxx.32 255.255.255.252 is directly connected, outside
S    172.16.11.0 255.255.255.0 [1/0] via 10.0.10.2, inside
S    172.16.2.0 255.255.255.0 [1/0] via 10.0.10.2, inside
S    172.18.11.0 255.255.255.0 [1/0] via 10.0.10.2, inside
C    10.0.10.0 255.255.255.0 is directly connected, inside
S    10.1.1.0 255.255.255.0 [1/0] via 10.0.10.2, inside
S*   0.0.0.0 0.0.0.0 [1/0] via xxx.xx.xxx.34, outside
0
 
asavenerCommented:
Did you enter "access-group phone_acl in interface phone_test"?
0
 
jplagensAuthor Commented:
I didn't. I just added it.

After adding it, I can only ping the phone_test interface of 172.16.100.1.  I can't ping the voice vlan on the router at 172.16.2.1 and I can't even ping the inside interface on the ASA at 10.0.10.1.
0
 
asavenerCommented:
Run the packet tracer in the ASDM, and use the phone_test interface as the inbound interface.
0
 
jplagensAuthor Commented:
I finally figured this out after months and months of beating my head against the wall.  If someone can explain the reason why this fixed the problem I would be very appreciative.

The first issue is that I didn't have the "AnyConnect for Cisco VPN Phone" license.  Once I installed that license I still had the same problem.

The resolution was to add a static route on the router to send the SSL vpn traffic back to the ASA firewall.  

The router already had the default route as:
ip route 0.0.0.0 0.0.0.0 10.0.10.1

I would assume that would send all traffic back to the ASA.  

I left the default route as is and added:
ip route 172.16.101.0 255.255.255.0 10.0.10.1

Once I did that everything started working.

The question now is why do I have to explicitly define the route for the SSL vpn traffic and why does the default route not send that traffic back to the ASA????
0
 
jplagensAuthor Commented:
Finally resolved the issue.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 17
  • 13
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now