Today I came across a very annoying issue of not being able to reach inside interface of Cisco ASA over Site-to-Site VPN or Anyconnect VPN client. Connectivity to the internal networks was ok. I was able to connect and manage it from inside host. VPN subnet was part of the allowed ssh and http list. ASA logs were not very helpful indicating connection was initiated over VPN but no two-way traffic. Quick on-line search gave me a few options to try: nat-control, outside NAT, check ACL, enable “management-access inside”, ssh/http allow rules.
Cisco ASA: 9.4.1
I’ve tried outside NAT but it did not make it any difference, and all else was already in place. My next step was packet tracer.
Tracing from outside can be a bit tricky. First of all, I always trace from the command line. It is quicker and provides information which may not stand out in the GUI tracer. Secondly tracing with Outside interface as a source may (occasionally) not classify VPN traffic properly and some modification may be needed. That’s is exactly what happened to me in this case.
access-group outside_in in interface outside
I knew this was not the issue because the following statement was present in my config
sysopt connection permit-vpn
so I’ve added a temp allow statement for VPN pool to my outside ACL and ran packet tracer again. This time, a got a lot further down the path but still got dropped by WEBVPN-SVC on the last step.
Forward Flow based lookup yields rule:
At this point, I knew it was not my NAT or ACL. The name WEBVPN-SVC was not very intuitive and did not provide any ideas of which way to look next. I’ve decided to circle back to my original searches and take a closer look at the NAT configuration.
I’ve noticed that route lookup option was unchecked. This option performs a route look up for this specific rule and helps forward traffic back out to Outside interface. That is exactly was I was missing in my logs – return traffic. After enabling this option I was able to access inside ASA IP address and my final rule looks like the following:
nat (inside,outside) source static OG_RFC1918 OG_RFC1918 destination static OG_RFC1918 OG_RFC1918 no-proxy-arp route-lookup
- Randomize your search when looking for solutions online. Instead of Anyconnect use VPN, instead of reach use remote. I was almost done with this post when came across Remote Management Access through VPN on ASA 5505 and found the answer right away.
- If ASA logs are not reporting any issues with NAT or ACL run packet tracer from CLI. It may give you additional clues.
- The devil is in the detail. Even if everything looks right, reviewing configuration options and referencing Cisco Configuration docs may shed some light on the issue.