cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2478
Views
0
Helpful
5
Replies

Remote Access VPN Connected, IP allocated, but can't access anything

Dean Romanelli
Level 4
Level 4

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

5 Replies 5

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,

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

HTH

Rick

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

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).

 

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

HTH

Rick
Getting Started

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: