One way vpn traffic

Unanswered Question
Jun 30th, 2011
User Badges:

I have a lan2lan tunnel between an ASA 5510 at my HQ office and an ASA 5505 at a remote site.  At the HQ site I have 4 subnets behind the ASA:

x.x.0.0 /24

x.x.10.0 /24

x.x.11.0 /24.

If I try to access a device at the remote site from the x.x.0.0/24, the tunnel will come up without any problems.  If I try it from either of the other two networks, I am unable to establish the tunnel from HQ.  However, if I ping a device on the x.x.10.0 /24 or x.x.11.0 /24 network from the remote site, the tunnel will come up and then I have two way communication between the networks without any problems.

I've had TAC verify my configuration.  I've checked my crypto ACLs to verify that both networks are interesting traffic.  Both networks are part of my nonat access-list on both ends.  Tried upgrading the IOS on the ASA, no luck there.  I have three other sites with the same configuration and they aren't having any problems. 

I've been working on this for a few days and TAC & I are both stumped.  I'm nowhere near an expert at ASA configuration so I'd appreciate some help.  I think the TAC engineer said it was failing at Phase 2.  Any suggestions

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Federico Coto F... Sat, 07/02/2011 - 12:58
User Badges:
  • Green, 3000 points or more


I know that you have checked your ACLs for interesting traffic but are they a exact match (IP/mask) on both sides?


chevymannie Tue, 07/05/2011 - 07:15
User Badges:

Yes.  I've verified that subnet mask on both sides is /24 for the interesting traffic and nonat access-lists.

aeryilmaz Tue, 07/05/2011 - 08:36
User Badges:

What about the ACL on the outside interface on the remote side? Are you allowing all subnets access inbound?

Also, I like to check the IPSec SA stats to ensure the HQ firewall is encrypting the traffic for each subnet (i.e. sending it down the tunnel). To do that you should first clear your counters:

clear cry ip sa counters (command may differ depending on your version)

Next run: show cry ip sa peer

Run the command as you send interesting traffic to one of the subnets not working and confirm you see encaps incrementing:

#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9

Review the stats in "show cry ip sa peer " and confirm if there are any send/receive errors?

    #send errors: 0, #recv errors: 0

This will just help you confirm if traffic is getting sent down the tunnel. If yes, then the config problem is on your remote end.

Hope this helps.

andamani Wed, 07/06/2011 - 09:38
User Badges:
  • Cisco Employee,


Can you check if there are any other peers defined at a lower sequence number with the same intersting traffic.? If yes can you bring the concerned peer at a lower sequence.


access-li vpn1 permit ip host host

access-list vpn2 permit ip host host

cry map clientmap 1 match address vpn1

cry map clientmap 1 set peer

cry map clientmap 2 match address vpn2

cry map clientmap 2 set peer

Hope this helps.



P.S.: please mark this thread as answered if you feel your query is resolved. do rate helpful posts.

chevymannie Fri, 07/08/2011 - 07:35
User Badges:

As I stated earler.  Already checked my NAT and interesting traffic ACLs.  TAC also looked through my configuration about six times and said it was good.

mvsheik123 Fri, 07/08/2011 - 09:38
User Badges:
  • Gold, 750 points or more

Very interesting & frustrating. It seems you checked all the possible areas to resolve the issue. Not sure if this helps , but..

1. Is there any IPS at HQ or Remote site (connected to outside of ASA)

2. The ISP at remote site has any special config for ICMP traffic?

3.did you check if the ping initiated from HQ is dropping somehwere? (debug icmp echo on ASAs)



ju_mobile Fri, 07/08/2011 - 10:02
User Badges:


isakmp nat-traversal is not a NAT acl. I guess we could offer input but without seeing all the details and or having an understanding of your exact setup it's difficult to offer aspects that may impact the cause of one way traffic.

Apart from NAT-T it's also worth checking PFS if its enabled at both ends. If you wish to consider further input then might I reccomend a review of your sanitised config's to offer a review against. It could be beneficial as highlihted by mvsheik to verify the environment outside of the VPN.




This Discussion

Related Content