Cisco ASA - NATing incoming Remote Access connections to inside network

Folks,

Does anyone know if you can setup a PAT for remote access clients coming into the ASA server for traffic destined inside the network?  I have an ASA 5510 that is going to require 4 VPN clients coming in; to avoid internal routing changes, etc, is it possible or even advisable to try to have a PAT for the VPN clients to appear on the inside of the network PATing from the ASA's internal interface?   So far in trying to do this with NATing or a Policy NAT, I haven't been able to make it work.  Just doing an ICMP ping to the first hop router inside the network on the segment the internal interface the ASA is on, I get the following:

Built dynamic ICMP translation from Outside:10.1.1.1/768 to Inside(Outside_pnat_inbound):10.100.0.1/1

followed by for every ping attempt:

No translation group found for icmp src Outside:10.1.1.1 dst Inside:10.100.0.1 (type8, code 0)

It looks to me like it is setting up the translation judging by the first log message, but then the subsequents look like it is failing.

Any info or advice on this approach appreciated!  I am new to working with the ASA, so perhaps my approach is fundamentally flawed, so any recommendations on the best way to handle this I'm open to.

Regards,
Jeff
docsteelAsked:
Who is Participating?
 
stressedout2004Commented:
Those lines are necessary. It prevents internal users from losing internet access.
0
 
stressedout2004Commented:
This is going to be very tricky. I haven't tried it over IPSEC before, but I have tried it using regular traffic.
Although not recommended, since you only have 4 clients that will be coming in, can't you just grab a free
IP within the same internal network and use it as VPN pool? I'll try testing my config for clear traffic and apply it
on IPSEC and see how it works. Not sure how fast I can get back at you with this though. Maybe someone else out there
has a better idea.
0
 
docsteelAuthor Commented:
I'd like to but the Cisco platform generally doesn't let you set internal IP's in ranges already recognized as being in the network for VPN clients.
0
The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

 
stressedout2004Commented:
True, because more often than not, it causes the VPN clients to not be able to pass traffic. So Cisco does not recommend its usage.  I have implemented it on various occassion and 90% of the time it worked for me (PIX, router and VPN 3000 setup). I haven't tried it on the new ASA platform.  Anyways, i'll test it out and see how it work. I don't have an ASA to test on, but I'll try it with the PIX 7.0 which is the same code that ASA runs on.
0
 
stressedout2004Commented:
I did a test in the lab and the following configuration worked for me.

Topology Used:

10.1.0.0/16------ISA Firewall ----192.168.0.0/24---PIX --internet--VPN Client


ISA firewall

internal IP 10.1.2.1/16
external IP 192.168.0.215/24
gateway pointing to 192.168.0.216 which is a router going to a totally different network
with no route back to the PIX or to the 192.168.100.0/24

PIX firewall
internal IP 192.168.0.1

Test PC 10.1.2.2 with gateway pointing to ISA

Application used to test: RDP

From my setup, the only time the VPN Client will be able to communicate with 10.1.2.2
via RDP is if the outside NAT works, because the ISA server doesn't know how to
route back 192.168.100.0/24 (VPN Pool).


#############################################################################
Config Used (VPN config excluded):

ip local pool vpn_pool 192.168.100.1-192.168.100.3

access-list inside_outbound_nat0_acl permit ip 10.1.0.0 255.255.0.0 192.168.100.0 255.255.255.0

access-list outside_nat deny ip host 192.168.100.1 any
access-list outside_nat deny ip host 192.168.100.2 any
access-list outside_nat deny ip host 192.168.100.3 any
access-list outside_nat permit ip any any

global (inside) 2 interface

nat (outside) 0 access-list outside_nat OUTSIDE

nat (outside) 2 192.168.100.1 255.255.255.255 OUTSIDE 0 0
nat (outside) 2 192.168.100.2 255.255.255.255 OUTSIDE 0 0
nat (outside) 2 192.168.100.3 255.255.255.255 OUTSIDE 0 0

nat (inside) 0 access-list inside_outbound_nat0_acl

***the word OUTSIDE is a must

Debug output:

305011: Built dynamic TCP translation from outside:192.168.100.1/1151 to inside:192.168.0.1/1036
302013: Built inbound TCP connection 49161 for outside:192.168.100.1/1151 (192.168.0.1/1036) to inside:10.1.2.2/3389 (10.1.2.2/3389)

Show xlate:
PAT Global 192.168.0.1(1036) Local 192.168.100.1(1151)

Show conn:
TCP out 192.168.0.1(192.168.100.1):1151 in 10.1.2.2:3389 idle 0:00:52 Bytes 25082 flags UIOB

#############################################################################

So as you can see, you will still need to assign a pool for the VPN client which is from a different
subnet being used internally. Then apply outside NAT on the IP pool. You still need to create the regular
nat(inside) 0 because the NAT will take place twice.

Please take note that this config is tested on PIX and not ASA. However, PIX 7.x and ASA has the same
code with minimal enhancement for the ASA. So it should work just the same. Hope it works for you.
0
 
docsteelAuthor Commented:
Thanks for the help!  I am getting ready to try this adapted to my configuration, but one question: are the lines indicating access-list outside_nat deny ip host 192.168.100.X any simply there is you wish to limit those VPN users from going to the outside (Internet most likely) or are they necessary?  I would think that its the former as an example of good practice.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.