?
Solved

Cisco ASA - NATing incoming Remote Access connections to inside network

Posted on 2006-04-19
6
Medium Priority
?
494 Views
Last Modified: 2013-11-16
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
0
Comment
Question by:docsteel
  • 4
  • 2
6 Comments
 
LVL 9

Expert Comment

by:stressedout2004
ID: 16490914
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
 

Author Comment

by:docsteel
ID: 16492041
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
 
LVL 9

Expert Comment

by:stressedout2004
ID: 16492563
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
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as high-speed processing of the cloud.

 
LVL 9

Expert Comment

by:stressedout2004
ID: 16494448
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
 

Author Comment

by:docsteel
ID: 16501609
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
 
LVL 9

Accepted Solution

by:
stressedout2004 earned 2000 total points
ID: 16515182
Those lines are necessary. It prevents internal users from losing internet access.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the…
This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
Screencast - Getting to Know the Pipeline
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question