04-24-2015 12:54 PM - edited 02-21-2020 08:12 PM
Hi All,
I set up a new remote access VPN tunnel on my ASA so that home users can connect in. I am finding that the tunnel connects, and my PC running the client gets an IP address from the remote ASA, but I can't access any LAN resources. My config is below, can someone tell me what is missing:
I have tried nat-traversal, ipsec-udp enable, same-security permit, set reverse-route, inspect icmp, sysopt connection permit-vpn, and probably a few others I am forgetting. I am on ASA code 901-k8.
ip local pool RemoteAccessPool 192.168.188.1-192.168.188.254 mask 255.255.255.0
interface Vlan1
nameif inside
security-level 100
ip address 192.168.169.254 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 78.xx.xxx.174 255.255.255.252
route outside 0.0.0.0 0.0.0.0 78.xx.xxx.173 1
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
object network LAN
subnet 192.168.169.0 255.255.255.0
object network VPNPOOL
subnet 192.168.188.0 255.255.255.0
nat (inside,outside) source static LAN LAN destination static VPNPOOL VPNPOOL no-proxy-arp route-lookup
access-list inside_access_in extended permit ip any any
access-list outside_access_in extended permit icmp any any
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
access-list RemoteAccessVPN_splitTunnelAcl standard permit 192.168.169.0 255.255.255.0
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto ca trustpool policy
crypto isakmp nat-traversal 30
crypto ikev1 enable outside
crypto ikev1 policy 120
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
management-access inside
group-policy RemoteAccessVPN internal
group-policy RemoteAccessVPN attributes
dns-server value 192.168.169.1 192.168.169.2
vpn-tunnel-protocol ikev1
split-tunnel-policy tunnelspecified
split-tunnel-network-list value RemoteAccessVPN_splitTunnelAcl
default-domain value xxxxxxxxx.mcs
username dromanelli password DU776HzHqftCNw5L encrypted privilege 0
username dromanelli attributes
vpn-group-policy RemoteAccessVPN
tunnel-group RemoteAccessVPN type remote-access
tunnel-group RemoteAccessVPN general-attributes
address-pool RemoteAccessPool
default-group-policy RemoteAccessVPN
tunnel-group RemoteAccessVPN ipsec-attributes
ikev1 pre-shared-key *****
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 4096
policy-map global_policy
class inspection_default
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rtsp
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect icmp error
inspect pptp
inspect icmp
inspect dns preset_dns_map
inspect ftp
inspect ipsec-pass-thru
policy-map type inspect ftp FTP-strict
parameters
mask-banner
mask-syst-reply
04-25-2015 10:08 PM
Hi Dean,
I would recommend you on this case to use another IP pool, I know that you may assure that the range is ot being used, but for routing wise lets try that. Lets say use a 10.X.X.X/24 range that is not being used and try again, make sure the (Management-access inside) command is configured.
Afterwards do a packet tracer like this:
packet-tracer input inside tcp 192.168.169.15 8080 10.x.x.x detailed
Attach this, make sure to try to access the inside interface first using TCP such as SSH, and ICMP.
Please don't forget to rate and mark as correct the helpful Post!
David castro,
Regards,
04-26-2015 10:53 AM
David
I am puzzled why you suspect that 192.168.188.0 is being used but seem so confident that 10.x.x.x is not.
This seems to be a very simple setup. There is an inside interface with a subnet. There are no routes to any other addresses inside, so it seems reasonable to me to assume that no other network is used inside.
Dean
I do not see any obvious issues in the config that you posted. I would comment that if the access lists and access groups were intended to get the VPN access to work that they are really not needed. My experience has been that when you configure Remote Access VPN on ASA that the VPN clients are enabled to access the inside network by default.
I wonder if the issue that you are facing is that devices inside do not have a route to the 192.168.188 network?
I do like David's suggestion of using packet tracer to be sure that the issue is not some policy on the ASA.
HTH
Rick
04-26-2015 12:05 PM
Hi Richard,
It makes sense, the customer is not using a dynamic routing protocol or static routes, now that's why I recommended to enable "management-access" in the inside interface to make sure he can access that, and if he is not able to access further than that would be to set up a static route on the L3 device behind the fw to send back the packet through the inside. Now about the 10.x.x.x range it was just a way to discard a behavior, or any scalability of the network in the 192.168.x.x range. :)
Dean let us know how it goes out!
David Castro,
Regards
04-27-2015 07:16 AM
Hi Rick / David,
Thanks for your comments. I spent the majority of last Friday trying to figure this one out but towards the end of my day I decided to open a case with Cisco. They were able to provide the answer, but to explain it I need to give just a bit of background below in italics.
This particular site is a branch/spoke, that connects back to two data centers via static site to site VPN; One data center for server access / email etc... and the other for internet access.
So when you are providing ultimate internet access to a site from a centralized location (i.e. data center), the VPN tunnel crypto ACL from the spoke site needs to be a "permit LAN subnet to Any" crypto ACL, (since it's impossible to list all of the internet's subnets in the ACL). So what was happening is that I was able to connect to the site via Remote Access VPN, but the return traffic (i.e. coming from the branch LAN) was always matching against that "permit lan to any" crypto ACL for the site-to-site tunnel to the data center providing internet. So instead of that return traffic coming to my laptop running the Cisco VPN client, it was being sent to the data center providing internet to the site, because apparently dynamic crypto maps are evaluated after all static crypto maps are evaluated. So the map for the remote access never had any interesting traffic, because it was always caught by the "Any" ACL for the static map to the data center.
Solutions are A) Break the internet out locally at the branch (bad idea), 2) Configure the remote access VPN on the core and hairpin the remote access subnet back to the branch over the static tunnel (not fond of this idea because of the backdoor potential it creates). 3) Move servers from branch site physically to the data center (probably what were going to do).
04-27-2015 08:54 AM
Dean
I am glad that Cisco TAC was able to identify the issue. This is a quite interesting situation and with the additional context information that there are site to site VPN along with the Remote Access VPN then the explanation makes sense. Thank you for posting back to the forum to let us know that there is a good explanation and what the potential solutions are.
HTH
Rick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: