nat one private ip to three different private ips

Unanswered Question

This is what I need to do.

Our internal network needs to connect to three other private networks over ptp t-1 lines.  Each of those private networks require a one to one connection per ip for security purposes.  Can I nat one private IP to three different private IPs and is it relatively painless?  We just purchased redundant ASA5510s and I was told the best place to do this would be on the ASA vs our 3945.

For the scenario below, can someone help me get started?

Our inside private network is     10.10.10.x /24 (security levl 100)

our vendor1 private network is     20.20.20.x /24 (sec lvl 25)

our vendor2 private network is     30.30.30.x /24 (sec lvl 25)

our vendor3 private network is     40.40.40.x /24 (sec lvl 25)

Lets say our internal pc has a

would something like this work (barring syntax errors)?

static (inside,vendor1) netmask

static (inside,vendor2) netmask

static (inside,vendor3) netmask

Is this one way to do it?  is there a better way realizing that I have about 70 computer which calculates to about 210 nat statements (ugh)


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Nagaraja Thanthry Thu, 08/19/2010 - 17:56


That would work. The only thing is you got the addresses reversed. Correct format would be:

static (inside,vendor1) netmask

static (inside,vendor2) netmask

static (inside,vendor3) netmask

Hope this helps.



Jeremy Buck Fri, 08/20/2010 - 07:57

Hey guys,

This solution would work if you have the flexibility to dedicate a single interface per customer or use a firewall on a stick. If you don't have that option then you would need to accomplish the same configuration over a single outside interface. You can accomplish the same thing over a single outside interface if you use "conditional Static NAT" or "static NAT with an access-list."

Conditional Static NAT would look something like this:

static (inside,outside) access-list remote_site1

static (inside,outside) access-list remote_site2

static (inside,outside) access-list remote_site3

! each ACL represents the remote networks which will access the static translation

access-list remote_site1 permit ip host

access-list remote_site2 permit ip host

access-list remote_site3 permit ip host

What this does is create 3 separate translations for the same internal box depending on the remote network involved. Since it is a static it works for both inbound and outbound traffic (statics are forever established).

End result:

Traffic inbound or outbound from will hit to access

Traffic inbound or outbound from will hit to access

Traffic inbound or outbound from will hit to access



I appreciate your reply, but I'm not sure I completely understand it. Is your "end result" a many to one or a one to one? My vendors need to know exactly what computer (based on IP) the information is going to at all times because they will come in and audit to make sure which computers can access their networks.

For example:

If my internal ip is, theres will be

If my internal ip is, theres will be

A on my side can never be a 20.20.20.x, it must be a .3 always. I was a little confused by your subnet mask not being a Does your solution provide a one to one like my example above?

Thanks again for your reply.

Manish Naik Fri, 08/20/2010 - 09:52

Hello David,

                 The config that Jeremy mentioned is for one to Many Translation, in your case in the acl if instead of the /24 if you mention /32 that should do the trick for you.

access-list remote_site1 permit ip host

access-list remote_site2 permit ip host

access-list remote_site3 permit ip host

  Jeremy correct me if I am wrong,


Jeremy Buck Mon, 08/23/2010 - 09:03


The example I provided is a one-to-one translation that is conditionally matched to a single remote (source) network. You could debate that it is "one-to-many"  if you wanted to, but the actual XLATE entry created is one-to-one, for each instance of the translation there is one inside address and one outside address /32. Conditional static NAT is one of the most flexible configurations available on Cisco ASA/PIX hardware. I've used this configuration with 7.2.3 and 8.4+ code on all ASA models. It's a bit difficult to understand the syntax initially, but once it clicks you will greatly appreciate what it can offer!

By specifying the /32 host IP in the static command and the keyword "host" in the access-list command you are creating a one-to-one /32 translation which will be placed in the XLATE table for any sessions initiated or destined to/from the remote network (which immediately follows the host in access-list). So this NAT is always tied to the remote network...

You do not want to modify the access-list as Manish has suggested as that will change the translation so that it only works to/from a single remote host.

The translation is like this:

(A single inside host) is translated to (a single outside IP) via a static (which means it works for inbound and outboud traffic) but only for flows that are to/from the remote network (which immediately follows the inside address in the access-list, i.e. the /24). You can implement this configuration for each customer as follows:

Customer A, you will use to access the service.

Customer B, you will use to access the service.

Customer C, you will use to access the service.

... and they will all be hitting the same internal VIP or webserver over the same outside interface. This type of configuration is perfect for situations where the customer cannot route the address that you have NAT'd the service to on a global-static level.

----------------------Another example----------------------------

Let's say you NAT'd the internal service as follows:

static (inside,outside) netmask

... and there are no other translations in the firewall.

Then Customer A says, "I cannot route to" because I am using the network internally. Well..., you can't change the static because Customer Z is using to hit the VIP through the global static. If you change the global static you will break Customer Z. So now you are forced to either create a new VIP, new webserver, or do NAT somewhere else, right? No! You can NAT the internal service ( to a different address, one that Customer A can route to, through a conditional static!

static (inside,outside) netmask    <--- The existing global static

static (inside,outside) access-list customer_A_acl  <---- The new conditional static

access-list customer_A_acl permit ip host

show xlate



You can find further information on this subject in the Cisco, ASA, PIX, and FWSM handbook (that is where I leveraged the configuration from before placing into production).




This Discussion