Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VPN Traffic can only be initiated from one end of the tunnel

Hi, 

My setup is HQ and Branch are connected via IPSec VPN Tunnel. There are several subnets in HQ and only one subnet in Branch are needed for the VPN configuration. The tunnel works fine until this morning and it can only be initiated from Branch side. Both ends are ASA.

I checked ASP Routing table, it doesnot seem like the branch subnet is showing there. I also did packet-tracer and the packet dropped right already the NAT. So I am positive this is a routing issue, likely on HQ side.

The code running on HQ ASA is 8.4(6) and code running on Branch ASA 8.4(7). I tried to search cisco bug tool but failed to find any match...

Suggestions?

5 REPLIES
New Member

Still waiting for experts to

Still waiting for experts to light up here...

Super Bronze

Hi, I would like to see the

Hi,

 

I would like to see the "packet-tracer" full output and the actual command used.

 

You say it ends with error in some NAT Phase?

 

The traffic related to the L2L VPN configuration will naturally first need to match the proper NAT configuration and then it will match the L2L VPN configuration which will initiate the L2L VPN negotiation between the gateways.

 

Can you perhaps also share the output of this command while the connection is up

 

show vpn-sessiondb detail l2l filter ipaddress <peer ip address>

 

Or

 

show vpn-sessiondb detail l2l | begin <peer ip address>

 

For some softwares I have noticed that the first command does not work even though the VPN connection is up.

 

Have you changed anything related to NAT recently? Has there been any modifications/changes to the Branch office external connection that could cause this problem?

 

- Jouni

 

 

New Member

Thanks for the tips...It is

Thanks for the tips...It is fixed now after I failover the redundant pair...I am convienced that is a bug in 8.4(6) but I just can not find which one and we can not upgrade to 8.4(7) for some related VPN tunnel issue in that version.

I still attached packet-tracer output below. As you can see the subnets were un-nated but the VPN just doesnot take it. 

Super Bronze

Hi, Seems that the traffic

Hi,

 

Seems that the traffic fails in the Phase where the traffic is matched against the VPN configurations. I mean it matches the VPN configurations but at the moment that the "packet-tracer" command has been entered the L2L VPN connection is either not up already or it has tried to negotiate but it has failed. Notice though that if the L2L VPN connection is down when the "packet-tracer" is first entered to the ASA then the first time will always fail. This is because it first command only initiates the VPN negotiation and the second time you enter the command the VPN negotiation should already gone through. If not then there is naturally a problem.

 

I have had some similiar problems with ASA Failover pairs and VPN but in software level 8.2 only so far.


Once the problem was when migrating a L2L VPN connection by changing the remote peer IP address. After we had to roll back and change back to the old peer one subnet of the L2L VPN connection failed negotiation just like above. A change in the Active device corrected the problem.

 

In other situation a L2L VPN connection that had been operating fine for 1 year stopped working for a single subnet. The "packet-tracer" test suggested that everything was fine but the traffic was not forwarded to the VPN connection. It seemed like the traffic was forwarded unencrypted through the firewall. Again, changing the active unit in the Failover pair corrected the situation.

 

Both cases have only happened once to in the space of 6 years so have not really been that common. I guess it might be possible that its such an uncommon bug that it has not been reported/recorded on Ciscos side.

 

I guess the only way to be sure would be to debug the problem but usually its not option in a situation where the VPN connection is used actively and production environments depend on it :)

 

 - Jouni

 

 

New Member

Agreed. It is not affecting

Agreed. It is not affecting production per-say but when it happens (couple times a year maybe), it is really annoying and people kept coming ask what is going on...

I guess it is just me, I got scared when asked to do debug on ASA...

516
Views
0
Helpful
5
Replies
CreatePlease login to create content