ASA 5510 Allow Inside Hosts access to VPN Clients

[smudley]

We have a ASA 5510 and it's setup to allow remote Cisco VPN clients access to our inside network.

How do we set up the ASA to allow inside hosts access to the VPN clients.

We want to use remote desktop software called 'Dameware' to provide desktop assistance to VPN clients.

My VPN clients are assigned a 10.70.8.0 address and we cannot ping any 10.70.8.0 address from inside a 10.70.0.0 network.

Any tips that lead me into the right direction will be greatly appreciated.

 

[unclerico]

Brent, why is it thinking that traffic coming from 10.80.1.27 is traversing the firewall to or through the management network?? i have been scouring the config and I'm not seeing it.

global (INSIDE) 1 interface
nat (OUTSIDE) 1 access-list OUTSIDE_nat_outbound
nat (INSIDE) 0 access-list nonat_inside
nat (management) 0 0.0.0.0 0.0.0.0

this looks a little backwards. it usually looks something like this:

global (OUTSIDE) 1 interface
nat (INSIDE) 1 access-list OUTSIDE_nat_outbound
nat (OUTSIDE) 1 10.70.8.0 255.255.240.0
nat (INSIDE) 0 access-list nonat_inside

you may have a reason for configuring it like you did, i don't know.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[smudley]

I had two 5 hr. sessions with a Cisco VPN engineer and he was scratching his head. I think he added the nat's. He did so much I couldn't keep up.

Smudley

 

[unclerico]

i'm assuming it's past the point of being able to back up the current config and start from scratch??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[smudley]

Other than wiping and reloading the factory cfg's this is pretty straight out of the box.

I used the ASDM to set it up cause I'm not great on the CLI

Smudley

 

[Supergrrover]

smudley & unclerico -
I agree. Something just isn't right here. Can you give a topology with those networks and how they attach (firewall, internal routers, VPN cloud, etc.) The routes just seemed odd.
This is a superset of your inside network
10.70.0.0 255.255.0.0 but you have it pointed to
10.70.2.3. Just weird...
Maybe a picture would get my head wrapped around this. (Give all interfaces the proper IPs and networks between and mask the middle 2 octets of the public IPs but leave the rest as they are.)

We might have to end up nuking it and start over but I want to do as little as possible so your clients stay up.

Just as a note for later - keep a record of all changes techs make to your config and save them as versions (I like SecureCRT as it does it auto.) Then ask them explicitly why they are making the change and what it does. One, you can learn something, but if your BS detector goes off it might be time to escalate to a higher level tech.


Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[smudley]

Brent
I tried to keep up with the changes and I do use SecureCRT (but an older version) but after 5 hrs. of him changing/testing it all got messed up.

Oh, and it was escalated to the VPN engineer (level 3?)

Attached is a brief topology.

Smudley

 

[Supergrrover]

These look good -
route INSIDE 10.80.0.0 255.255.0.0 10.70.2.3 1
route INSIDE 10.81.0.0 255.255.0.0 10.70.2.3 1
route INSIDE 10.83.0.0 255.255.0.0 10.70.2.3 1
route INSIDE 10.84.0.0 255.255.0.0 10.70.2.3 1
route INSIDE 140.140.128.0 255.255.240.0 10.70.2.3 1

This
route INSIDE 10.70.0.0 255.255.0.0 10.70.2.3 1
is off. This network is directly connected to the ASA. You shouldn't have it as a route. It is telling the ASA to route all traffic destined to 10.70.0.0-10.70.255.254 to go to the router at 10.70.2.3. (This is inclusive of traffic bound for 10.70.8.10 255.255.240.0.)

Problem #2 - Your ACLs need to be more specific. They reference your internal network (ip address 10.70.2.24 255.255.240.0) by a mix of
10.70.0.0 255.255.0.0 AND 10.70.0.0 255.255.240.0
These
access-list nonat_inside
access-list OUTSIDE_nat_outbound
have to be fixed to be more specific.

Problem #3 - Your VPN pool is inside your internal network. This is almost always trouble. Change the VPN pool to something outside of your internal network - greater than 10.70.15.254. Change ACLs accordingly.

This is mighty close to a rebuild but I think it can be salvaged. It will take some work and testing.

Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[smudley]

Brent
Thanks for the help.
I've been told to wait till Monday to make changes since this is our month-end.

But then, I'm going to:

Remove route INSIDE 10.70.0.0 255.255.0.0 10.70.2.3 1

Change my address pool to 10.70.88.0 255.255.255.0

But I'm not sure I understand how to make the ACL more specific:
I don't see 10.70.0.0 255.255.240.0 in the cfg.
Should I remove access-list OUTSIDE_nat_outbound extended permit ip any 10.70.0.0 255.255.0.0 ?

Problem #2 - Your ACLs need to be more specific. They reference your internal network (ip address 10.70.2.24 255.255.240.0) by a mix of
10.70.0.0 255.255.0.0 AND 10.70.0.0 255.255.240.0
These
access-list nonat_inside
access-list OUTSIDE_nat_outbound
have to be fixed to be more specific.

Smudley

 

[Supergrrover]

access-list OUTSIDE_nat_outbound extended permit ip any 10.70.0.0 255.255.0.0
should be
access-list OUTSIDE_nat_outbound extended permit ip any 10.70.0.0 255.255.240.0
and this
access-list nonat_inside extended permit ip 10.70.0.0 255.255.0.0 10.70.8.0 255.255.255.0
should be
access-list nonat_inside extended permit ip 10.70.0.0 255.255.240.0 10.70.88.0 255.255.255.0

to match your internal network mask.

As usual - back up your config and do it after hours so you have time to recover if there are problems.

Brent
Systems Engineer / Consultant
CCNP, CCSP