Hello, After a few recent changes on the firewall, one of our Site-to-Site VPN connections is experiencing one-way traffic. The VPN connection actually connects two IP addresses on our side with a subnet on the other. Because of the two IP Addresses on our side, two IPSec tunnels are setup. One experiences full two-way traffic. The other only receives traffic. All traffic from our network destined for the second tunnel is dropped. I have done a sniff on the traffic and can see it coming in on our DMZ interface. I even setup the exact scenario for the packet tracer and it showed everything coming out ok. I feel it important to mention that the firewall does see the VPN connection as up and running and there is no problem with the first IPSec tunnel. The problem is that the firewall is dropping packets that should go out on the second tunnel.
Result of the command: "sh crypto ipsec sa detail"
You obfuscated the crypto map entries such that I don't know which one is associated with the peer 200.115.231.131 from your "sh cryp ip sa" output above. Which crypto map sequence number goes with the affected tunnel?
Can you verify that traffic is actually hitting the DMZ interface on the ASA, by doing a capture?
One way traffic like this is usually one of two things, Nat issues or Routing issues. I looked at your nat, and it appears to be configured correctly, so that would leave routing issues, before it gets to the ASA.
Because I have obfuscated the IP's for security reasons, I would like to email you the sniff's offline because they contain the real IP addresses. What is your email address?
Assuming you were addressing me and not FaithShield, my e-mail is on my profile page.
Try mirroring your NAT exemption ACL with your crypto ACL:
access-list dmz-nonat extended permit ip object-group DM_INLINE_NETWORK_1 object-group mansina no access-list dmz-nonat extended permit ip 100.2.83.0 255.255.255.0 any
Also, a couple of questions:
1. Is there a reason you disabled NAT-T on that tunnel? 2. Why do you have two transform sets applied to that crypto map that are defined identically? (ESP-3DES-MD5 and Verizon_IPSEC)
The NAT exemption list is for all the other servers in the DMZ as well. If that were removed we would lose connectivity for all our other servers not going through the VPN tunnel.
1) The reason I disabled NAT-T is because it doesn't work with the far end VPN endpoint. 2) I honestly don't know.
What type of VPN endpoint is this tunnel connecting to? Is it an Adtran Netvanta, by any chance?
I looked at the captures and saw how there was no traffic showing up on the outside interface capture, but I noticed that not only did the .43 traffic not show up, neither did the .42 traffic so this wasn't a good indication of what is happening. How did you construct the ACL you used for the DMZ interface capture? Did you do something like this?
After talking with Cisco Support for over 4 hours, the bug was forwarded to their development team as a possible bug. Unfortunately, we did not have the luxury of taking the time to troubleshoot the issue with them. In the middle of the night, I was able to reset the Firewall and everything worked as intended. (Moderator, please close the Question)