cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
437
Views
0
Helpful
5
Replies

ezvpn client to client IP connectivity not stable

oldcreek12
Level 1
Level 1

Hi, I have home ezvpn clients (851s) terminated on a headquarter ASA5520, those home workers may call each other at home with Cisco VoIP phone behind 851s, call managers are in HQ, those VoIP phones have corp extensions. Often times users complain voice is one way and sometimes they don't hear audio at all,although call signaling seem to be perfectly fine.

I did ping test between hosts behind 851s, it is strange that sometimes the ping works but some times it does not, ping to HQ always succeeds. I could not think anything wrong with my configuration because in that case ping between spoke-spoke won't work at all. Do you guys have any idea what area I may need to look at? Thanks a lot,

5 Replies 5

Not applicable

For spoke to spoke to work make sure you have the following command in your ASA:

same-security-traffic permit intra-interface

Hope this helps,

Jason

Hi, Jason,

Thank you for your response, I have that configured, otherwise ping will never be successful at all.

This is a big problem for us, what really bothers me is that the issue is totally random, spoke to spoke ping may work last minute then suddenly stops working. So this could not be a configuration issue. I suspect that ASA is not handling hairpin VPN traffic perfectly. We are running 7.2, should I upgrade to 8.0?

Appreciate you guys insight for this.

While searching NetPro archive, I came across this post, the author had exactly the same problem as I have. Unfortunately, the problem did not seem to be resolved either.

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Security&topic=Firewalling&topicID=.ee6e1fa&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cbef16c/5#selected_message

Firewalling: VPN Hairpinning Intermittent Issue

Posted by: gordon.hawkins - Network and Systems Admin, VANCOUVER FILM STUDIOS - Dec 21, 2007, 1:34am PST

Hello, I am using an ASA 5540 VPN edition to terminate VPN connections from software clients and PIX/ASA boxes using EasyVPN (in network extension mode).

I am trying to get the PIX/ASA remote networks and the VPN Clients to talk to each other (they both have no problems talking to the core) but intra-spoke communication is intermittent.

Just as an example, I was trying to ping from a client (192.168.200.4) to a remote network (192.168.8.1) and it wouldn't work, but when I initiated the ping from the remote network side (192.168.8.1) it started working "magically."

same-security-traffic permit intra-interface is enabled on the core pix.

Here is some of the relevant config:

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 172.16.1.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 172.16.2.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip any 10.1.131.0 255.255.255.224

access-list inside_nat0_outbound extended permit ip any 10.1.129.0 255.255.255.128

access-list inside_nat0_outbound extended permit ip any 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip any 10.1.6.192 255.255.255.192

access-list inside_nat0_outbound extended permit ip 10.1.6.0 255.255.255.0 10.1.6.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.240.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.17.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.18.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0

ip local pool VPN_CLIENTS 192.168.200.1-192.168.207.254 mask 255.255.248.0

global (outside) 1 209.17.173.11 netmask 255.255.255.0

global (outside) 101 209.17.173.9 netmask 255.255.255.192

global (DMZ) 101 209.17.173.9 netmask 255.255.255.192

global (DMZ) 2 192.168.1.8

nat (outside) 0 access-list inside_nat0_outbound

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 10.2.4.0 255.255.255.0

nat (inside) 101 172.18.1.0 255.255.255.0

nat (inside) 101 172.16.0.0 255.255.0.0

nat (inside) 101 10.0.0.0 255.0.0.0

nat (DMZ) 0 access-list inside_nat0_outbound

Help?

I found it interesting that when higher IP address client initiates the ping, the ping will be successful, but if the lower IP client initiates the ping, the ping will never go through ... what does this tell?

I think I am getting close ... I found that for a non-pingable 851 ezvpn client, the outbound SPI for spoke-to-spoke SA is 0x0, after continuous ping for some time, SA got re-created. Now question is why it is taking so long for a new SA to come up?

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:

Review Cisco Networking products for a $25 gift card