ezvpn client to client IP connectivity not stable

Unanswered Question
Oct 8th, 2008

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,

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Anonymous (not verified) Fri, 10/10/2008 - 04:30

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

jiangu Fri, 10/17/2008 - 13:45

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.

jiangu Fri, 10/17/2008 - 15:18

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?

jiangu Mon, 10/20/2008 - 22:44

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?

jiangu Tue, 10/21/2008 - 17:20

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?

Actions

This Discussion