cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
891
Views
0
Helpful
9
Replies

IP Phone Over ASA5505 VPN 1st Call Setup

jsadony
Level 1
Level 1

I have one PC and one 7940 IP Phone on the far side of a ASA5505. I created a VPN to an ASA5510 using the Easy VPN configuration (client mode not NEM). Everything works. Call quality is excellent. The only problem is on the very first call from the remote phone after the VPN comes up, I cannot hear the called party. After I hang up and call again the called party comes through loud and clear.

I notice that on the 5505 the client mode VPN starts on demand when the first IP traffic is sent. The connection opens up to 10 IPSEC tunnels. I am assuming one for each remote subnet. I can only assume that I cannot hear the remote party because of the fact that the tunnel to the far phone is not open when the call is initiated and sound from the called phone fails to reach the remote phone because of some timing issue.

Though I have note tested this yet, I will assume that I will have the same problem when calling phones on subnets that do not yet have an IPSEC tunnel.

Is this an inherent limitation of this VPN configuration? Is there a work-around?

Your advice is very much appreciated.

9 Replies 9

ggilbert
Cisco Employee
Cisco Employee

Hi Joe,

For the Easy VPN client in Client Mode, the IPSec SA is created for each and every subnet according to the split tunnel list that is sent from the head end side.

If you look at the IPSec SA, the ESP SA's will not be created until there is interesting traffic. Thats the behavior of an IPSec tunnel.

Also, in client mode, the traffic gets PATted on the client side to an address assigned by the Easy VPN server.

I am not a Voice expert but when the call is initiated - the packet travels through the tunnel and the call is picked up, the RTP stream should be established between the two phones, right? Do you see the RTP stream getting established?

Also, another thing to try would be NEM. See if that works out well. In most of the cases, NEM is used for Easy VPN when there is Voice involved.

Hope this helps.

Cheers

Gilbert

I would use NEM. The only issue with NEM is that I cannot get remote traffic to route beyond the host firewall's directly attached network. For example:

The remote subnet is 192.168.1/24

The host (or hub) firewall is directly attached to 10.1.1/24

Let's say the phone is 192.168.1.1. When the VPN is up in the client mode I can get to all nets beyond the host firewall as long as ACLs allow.

In NEM mode I can get to host in 10.1.1/24, but cannot get to host beyond that directly connected net. I originnally thought this was a routing issue, but having have ruled that out.

Some conversations on this board point to that being a limitation of NEM, but I've not gotten a difinitive answer on that yet.

Thanks!

Hi Joe,

I would like to ask you a question about your statement..."The only issue with NEM is that I cannot get remote traffic to route beyond the host firewall's directly attached network"

So, heres my question.

The remote side (Easy VPN client) is 192.168.1.x/24 and the head end side (Easy VPN server) is 10.1.1.x/24, which side of your topology does have more than one network.

Is it the remote side or is it the head end side.?

From your statement "In NEM mode I can get to host in 10.1.1/24, but cannot get to host beyond that directly connected net" I would presume it would be behind the head end side (Easy VPN server).

Is that correct?

Just making sure that I am understand what you are trying to do. Sorry about the questions.

If you are trying to access something behind the head end side, which is beyond 10.1.1.x/24 network, then NEM should work without any problems.

How many networks are there behind the 10.1.1.x/24 network?

What does your split tunnel access-list look like? (How many entries are there in that ACL)

Let me know.

Cheers

Gilbert

Gilbert,

No problem with the questions. I certainly appreciate you taking the time on this thread. Let me clarify:

?-- The remote side (Easy VPN client) is 192.168.1.x/24 and the head end side (Easy VPN server) is 10.1.1.x/24, which side of your topology does have more than one network.

Is it the remote side or is it the head end side.?

From your statement "In NEM mode I can get to host in 10.1.1/24, but cannot get to host beyond that directly connected net" I would presume it would be behind the head end side (Easy VPN server).

Is that correct? --?

You are correct. The head-end side has multiple nets beyond the 10.1.1.x/24 home net of the Easy VPN Server. There are about 20 subnets on the Server side. My problem is that the Easy VPN Client on 192.168.1.x/24 cannot get to those nets though it has not problem getting to addresses in 10.1.1.x/24.

Since we?re getting specific I may as well say that the real net of the head-end is 192.168.130.x/24 and not 10.1.1.x/24. Old habits die hard. Now my ACLs may make more sense:

access-list splitTunnelAcl standard permit 192.168.130.0 255.255.255.0

access-list splitTunnelAcl standard permit 172.30.254.0 255.255.255.0

access-list splitTunnelAcl standard permit 172.30.253.0 255.255.255.0

access-list splitTunnelAcl standard permit 172.30.0.0 255.255.0.0

access-list splitTunnelAcl standard permit 192.168.140.0 255.255.255.0

access-list splitTunnelAcl standard permit 192.168.120.0 255.255.255.0

I know the 172.30.x.x/16 access is redundant to the other two. I was troubleshooting this problem and haven?t cleaned up yet.

I started out using NEM, but couldn?t get the client subnet to route so I switched to the PAT client. I am not familiar enough with the ASA to know all of the troubleshooting tools available. I upgrade to the 5505 from a Linksys using IPSEC because the Linksys could not handle multiple tunnels. For a couple hundred more the 5505 is a great deal. There are a few bugs that Cisco seems to be working out, but I think the 5505 is the best deal going for a remote office VPN link.

Thanks!

Joe,

The NEM should work well without any issues for those subnets. When you use NEM, are the ACL's passed down to the client side and do see ipsec SA's created for these networks.

sh vpn-sessions remote --> (on the head end side) would give you some information on this.

I would like to see the group-policy for which this EzVPN tunnel-group should be connected?

Please let me know.

Thanks

Gilbert

Has this been resolved? I am having the exact same IP phone issue, though I don't have any network issues.

I have NEM enabled and my client is a PIX501 and the server is an ASA5520.

Thanks!

Mike

My voice problem came form the fact that I was running VPN on the 5505 in the client mode and not the NEM. This is normal behavior for the client mode since it opens up a new tunnel for every new network requested.

NEM is just as useful as it says it is. It extends the host network over a single VPN tunnel (or what seems to be a single tunnel). Once I got NEM configured correctly the voice over the VPN has worked 100%. The trick is in the configuration of the host firewall. My problem was that I was not exempting the remote network form being NAT'ed. The NEM mode will work but will only let you see one hop beyond the tunnel. Once I got that resolved, everything was OK.

Joe

How stable are your remote phones and what firmware are you running. I'm having an issue with the remote 7940 dropping, unregistering.

Our 5505's are running 7.2(2)19. We have one PC, and one phone at both installs. Voice quality is crystal and no periodic drops. The medium is cable, we have a local cable company that runs a very high quality network and has local peering with the ISP at the call manager location. We have an optimal situation with which to run voice over the net.

Cheers,

Joe

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: