07-21-2017 01:05 PM
Hi,
I am trying to configure site-2-site between two 5506x.
asa1 has outside IP 1.1.1.2 and inside 172.16.0.0/16
asa2 has outside 2.2.2.2 (from DHCP) and inside 192.168.1.0/24
The tunnel goes up no matter from what side I initiate the traffic but there is not return trafic.
If I initiate trafic from asa1 'show crypto ipsec sa' will show that it is encrypting traffic but not decrypting. If I run the same command on asa2 it say that it is decrypting but not encrypting.
If I take down the tunnel and then initiate the traffic from asa2 that asa will say that it is encrypting byt not decrypting and asa1 is decrypting but not encrypting.
To me that looks like the other side of the tunnel is receiving the packets but not returning it. I thought ASA is statefull so that it will always allow return traffic?
Trying to use packet-tracer command to t-shoot this but I am unsertain what interface to use?
I have included config from both ASAs.
Solved! Go to Solution.
07-22-2017 09:12 AM
Packet capture on ASA1 (filtered to capture only traffic to the web server address) while initiating traffic from your site b towards your web server at site a.
That should show the traffic leaving the tunnel and headed to the web server. If you don't see return traffic then it's not the ASA or the tunnel that's the problem.
07-21-2017 08:06 PM
Do the respective subnets each have the ASA's inside interface as their default gateway or route to the remote subnet?
07-22-2017 02:04 AM
On the asa2 side the subnet has the ASA as gateway. But on asa1 the default gateway is a L3 switch.
I thought this wouldn't be a problem since the tunnel was able to go up?
07-22-2017 02:14 AM
Hi,
On the ASA 1 put a static route
It should resolve the issue.
Regards,
Aditya
Please rate helpful and mark correct answers
07-22-2017 03:19 AM
On ASA1 I did "route outside 192.168.1.0 255.255.255.0 2.2.2.2 1"
That did not solve the problem.
Do I have to tell the core (L3) switch that it somehow should pass the trafic to the ASA tunnel?
07-22-2017 03:30 AM
Since ASA1 is not incrementing its encaps, it might not be receiving traffic from the internal subnet on its side of the tunnel.
Does the L3 switch know to route traffic destined for 192.168.1.0/24 to the ASA1 inside interface?
07-22-2017 04:31 AM
Now it does, but still not working.
ip route 192.168.1.0 255.255.255.0 172.16.61.23
There are no ACLs on the L3 switch, so I have ruled out that.
07-22-2017 05:01 AM
Hi,
Try testing with some other traffic.
Also, if
Also, you can enable the command management-access inside on ASA1.
And then try using the command:
ping inside 192.168.1.x
Regards,
Aditya
Please rate helpful and mark correct answers
07-22-2017 07:34 AM
On 172.16.63.63 I have a webserver. So I am using that to test http/s from 192.168.1.8.
(I don't trust ICMP :) )
'management-access inside' is already enabled on ASA1, but that ping did not work.
07-22-2017 07:42 AM
Hi Philip,
Try using debug
On ASA2 do you see
Now use debug
Regards,
Aditya
Please rate helpful and mark correct answers
07-22-2017 09:02 AM
Intresting. So this is what the result is:
If I ping from the inside of ASA2 to the inside of ASA1 I can see that the requests are comming to ASA1 but there is no reply.
If I ping from the inside of ASA1 I do not se the requests being forwarded from ASA1 to ASA2.
So my conclusion is that the traffic is getting stuck somewhere, ether in L3 switch or between the switch and ASA1. I do have an ACL on the inside interface of ASA1 but that permits any any ip.
Any other ideas?
Edit: I doubble checked the routing on the L3 switch and it shows that 192.168.1.0 is pointing to 172.16.61.23 (inside of ASA1).
07-22-2017 09:12 AM
Packet capture on ASA1 (filtered to capture only traffic to the web server address) while initiating traffic from your site b towards your web server at site a.
That should show the traffic leaving the tunnel and headed to the web server. If you don't see return traffic then it's not the ASA or the tunnel that's the problem.
07-22-2017 09:24 AM
You and Aditya have been on the right track the whole time. I found the source of the problem and it is not the ASA as you guys already have figured out.
Apparently there is a second L3 switch behind ASA1. This switch is gateway for 172.16.61.x.
The first L3 switch is gateway for every other 172.16.x.x network and there is about 60 of those. So I assumed and/or did not look carefully enough to see that 172.16.61.x was not on this switch.
When I added the routing to the second switch everything started to work.
So now I will put on my "I am ashamed"-hat and stand in the corner for 10min.
Thank you verry much for your help. Without you I would never have found a solution.
07-22-2017 09:05 PM
You're welcome. Thanks for letting us know the resolution.
No need to be ashamed - only if you repeat the mistake is that necessary. :)
Every one of these resolved issues is a good hands-on learning opportunity. I find that solving a real world problem by applying systematic analysis that it reinforces my knowledge of the uncerlying concepts much better than even the best book learning or classroom training.
07-22-2017 03:37 AM
Hi Philip,
Please add a reverse route on
Regards,
Aditya
Please rate helpful and mark correct answers
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide