ASA and PIX VPN not passing traffic

Unanswered Question
Jan 24th, 2009

I installed a new ASA firewall for a client that was using a PIX 501 as the network default gateway and VPN concentrator to three other locations. We do not have access to the remote locations to modify the L2L VPN tunnels to the new ASA on the new ISP. As a temp fix I've installed the ASA at the network DG, re-ip'd the existing PIX to another open LAN IP and added three route statements to the ASA for the VPN destination networks pointing to the PIX local IP. The ASA can ping across the VPN tunnels but the local LAN cannot. Is this a nat or traveral issue? Any help would be appreicated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Sat, 01/24/2009 - 17:41


I am not sure that I am understanding your description of the situation. Is it correct that the new ASA has the original internal network default gateway address and its outside interface address is a new address connecting to a new ISP? And is it correct that the existing PIX ouside interface still has its original address and its inside interface has a new address? And is it correct that the existing PIX is still terminating the VPNs?

If those things are true then I would ask whether you have cofigured the new ASA for same security level intra interface? Since the network traffic will be received on the ASA inside interface and need to be forwarded back out that interface then you need to enable intra interface forwarding (hair pinning) which is disabled by default.



j.bourque Sun, 01/25/2009 - 17:42

Yes your assumptions are correct. And yes I have issued both the same-security-traffic permit inter-interface and same-security-traffic permit intra-interface commands with no luck.

Richard Burts Sun, 01/25/2009 - 19:38


Here are a couple of thoughts:

- if an inside host sends data to the destination in the remote VLAN, then the packet goes to the ASA, which forwards to the PIX, which should process it with IPSec and send it through the tunnel. The response coming back would get to the PIX which would forward directly to the originating host. Is is assemetry of the path a problem?

- can you verify that when you originate traffic from some internal host to a remote VPN destination, can you verify that the traffic gets to the PIX and through the VPN? Is the encrypted count in the show crypto ipsec sa going up? You might also use the capture facility on the ASA to look for the traffic on the inside interface (look for traffic with the source address and then look for traffic with the destination address - if you see one then make sure that you see the other.

- if you can verify that traffic is going over the VPN, can you verify that responses are coming back? Is the decrypted count in the show crypto ipsec sa going up?




This Discussion