Timeline for Cisco ASA 5506-X - Site-to-Site VPN Tunnel - Return traffic dropped
Current License: CC BY-SA 3.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Nov 6, 2015 at 22:14 | comment | added | user315851 | I was able to resolve this issue and it was related to various things. One of the problems was at the far end not returning traffic properly due to it's ACLs. The other issue concerning the NAT'd Internet access problem was the 'class-map filtered-class' having the rule 'match any' which sent all traffic to the FirePOWER module that wasn't configured at all therefore it was dropping all traffic. I appreciate your assistance and marked your answer as correct since it certainly helped me answer some questions that led me to the right place. | |
Nov 6, 2015 at 22:10 | vote | accept | user315851 | ||
Oct 23, 2015 at 13:32 | comment | added | user315851 | Whoops, I took that line out to troubleshoot my non-VPN traffic NAT. It's been added back in since then as shown here: nat (inside,outside) source static Internal Internal destination static Datacenter Datacenter no-proxy-arp route-lookup | |
Oct 22, 2015 at 19:17 | comment | added | dareuja | For your vpn - you have decaps without encaps. For some reason the firewall is not encrypting the return traffic. You advised that a packet-tracer from inside to remote shows no issues. If this is the case, you may want to run a packet capture on the inside interface to verify traffic is going to the inside server and returning. Btw, the sh run nat does not match the nat statements in your configuration, you seem to be missing the identity nat for your vpn. | |
Oct 22, 2015 at 19:17 | comment | added | dareuja | Hello, from the packet tracer it looks like your traffic should be natting appropriately to the public interface IP. You may want to do a running ping from a server on the inside to 8.8.8.8 and check your xlate/nat table. If you do not see any entries, run a packet capture on the inside interface to make sure the traffic is reaching the firewall from the server. | |
Oct 22, 2015 at 13:36 | comment | added | user315851 | Hi dareuja, I've added the information you requested to my original post. Regarding access-list applied to the inside interface, you can see any access-list and where it's applied in the original configuration I posted. | |
Oct 22, 2015 at 5:43 | comment | added | dareuja | Also for the VPN issue, with traffic going across, what is the output of 'sh crypto ipsec sa peer x.x.x.x | i caps|local|remote'? (may want to scrub username and peer IP/T-group IP as well) | |
Oct 22, 2015 at 5:29 | comment | added | dareuja | Three q's - 1. What is the output of 'show run nat'? 2. What access list is applied to the inside interface? 3. What is the output of a packet-tracer sourcing from the inside interface going to 8.8.8.8? | |
Oct 22, 2015 at 4:31 | comment | added | user315851 | Hrmm, well that's no good. Thanks for testing and confirming that. Hard to trace where the breakdown in the path is unfortunately due to such. Care to take a look at my config and tell me why I my dynamic outbound NAT rules don't function properly? I just need the inside network (192.168.2.0/24) to be able to use the single public IP address on the outside interface for basic Internet access (a real Internet IP is on the outside interface, the config above is scrubbed and I used 172 addresses instead). | |
Oct 22, 2015 at 0:48 | history | edited | dareuja | CC BY-SA 3.0 |
added 147 characters in body
|
Oct 22, 2015 at 0:20 | history | edited | dareuja | CC BY-SA 3.0 |
added 64 characters in body
|
Oct 22, 2015 at 0:11 | history | answered | dareuja | CC BY-SA 3.0 |