I configured remote access VPN last night on a Cisco Router with the firewall feature set. No big deal right? My config was a little non traditional because I was applying the crypto map to the DMZ interface vs the internet facing interface. I had to do this because I didnt have the ability to test from the internet so I used a wireless client off my DMZ to test connectivity. I had everything configured such as ISAKMP policy, ISAKMP Group configuration, authentication and authorization. I configured the VPN Client to connect to the DMZ interface and Wallah! I was connected. I decided to ping a remote workstation to test connectivity and got that all too familiar error “Request timed out.”

This was a bummer. I wanted to get it right the first time. I started troubleshooting by looking at the log to see if maybe I forgot to make an access-list entry for the traffic. Everything looked good, no denies logged. I then looked at the nat translations. I saw an entry for the flow but the problem was that the return traffic was getting translated as my internet facing IP address. This is because of the nat rules I had in place. I thought this was kind of weird because the flow was going from DMZ to my lan facing interface not my internet facing interface to the lan interface.

So I did something I always hate myself for. I stopped thinking logically and immediate thought I needed NAT exemption. I configured an access-list with the denies defined for the VPN flow and allowed everything else out. Added the new nat statement and tried the ping again. Great, this time I didn’t see a translation to the internet interface but still no traffic.

After a bit more troubleshooting and wishing I had a dog I could kick I decided to configure remote access via the SDM … I compared configs and found the problem. The SDM had added the “reverse route” statement to the dynamic map. Immediately I knew why the traffic was not flowing correctly. If I hadnt disengaged from logical thinking I may have found this. When you apply a crypto map to the internet facing interface you usually also have a default route for that interface. When routing takes place in the router process the packet is forwarded based on route and then the crypto map picks it up. Since my crypto map was on the DMZ interface, the return traffic was getting compared to the routing table and forwarded to the internet interface due to no route pointing to the VPN pool on the DMZ interface. I checked the routing table after I reconnected and sure enough with the “reverse route” command , a route is placed into the routing table pointing the VPN pool IP address to the actual client IP which is located off of the DMZ interface. My pings were now working.

I fixed my initial config and I was good to go. If I had applied this to the internet facing interface I would not have had this issue but definitely a good troubleshooting experience. Below is a quick config for remote access VPN. Just apply the crypto map to the appropriate interface.

aaa authentication login vpnuserauth local
aaa authorization network vpnusers local
!
username joe password 0 ciscoiscool
!
!
!
crypto isakmp policy 7
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp client configuration group vpnusers
key cisco123
pool vpnpool
acl 100
!
!
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
!
crypto dynamic-map vpndynmap 1
set transform-set 3DES-SHA
reverse-route
!
!
crypto map vpnmap client authentication list vpnuserauth
crypto map vpnmap isakmp authorization list vpnusers
crypto map vpnmap client configuration address respond
crypto map vpnmap 1 ipsec-isakmp dynamic vpndynmap
!
!
!
!
!
ip local pool vpnpool 192.168.26.1 192.168.26.12
!
access-list 100 permit ip 192.168.40.0 0.0.0.255 192.168.40.0 0.0.0.255