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 10.10.10.1.
would something like this work (barring syntax errors)?
static (inside,vendor1) 10.10.10.1 126.96.36.199 netmask 255.255.255.255
static (inside,vendor2) 10.10.10.1 188.8.131.52 netmask 255.255.255.255
static (inside,vendor3) 10.10.10.1 184.108.40.206 netmask 255.255.255.255
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)
That would work. The only thing is you got the addresses reversed. Correct format would be:
static (inside,vendor1) 220.127.116.11 10.10.10.1 netmask 255.255.255.255
static (inside,vendor2) 18.104.22.168 10.10.10.1 netmask 255.255.255.255
static (inside,vendor3) 22.214.171.124 10.10.10.1 netmask 255.255.255.255
Hope this helps.
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) 126.96.36.199 access-list remote_site1
static (inside,outside) 188.8.131.52 access-list remote_site2
static (inside,outside) 184.108.40.206 access-list remote_site3
! each ACL represents the remote networks which will access the static translation
access-list remote_site1 permit ip host 10.10.10.1 172.16.83.0 255.255.255.0
access-list remote_site2 permit ip host 10.10.10.1 192.168.54.0 255.255.255.0
access-list remote_site3 permit ip host 10.10.10.1 172.16.99.0 255.255.255.0
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).
Traffic inbound or outbound from 172.16.83.0/24 will hit 220.127.116.11 to access 10.10.10.1
Traffic inbound or outbound from 192.168.54.0/24 will hit 18.104.22.168 to access 10.10.10.1
Traffic inbound or outbound from 172.16.99.0/24 will hit 22.214.171.124 to access 10.10.10.1
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.
If my internal ip is 10.10.10.1, theres will be 126.96.36.199
If my internal ip is 10.10.10.2, theres will be 188.8.131.52
A 10.10.10.3 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 255.255.255.255. Does your solution provide a one to one like my example above?
Thanks again for your reply.
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 10.10.10.1 172.16.83.1 255.255.255.255
access-list remote_site2 permit ip host 10.10.10.1 192.168.54.1 255.255.255.255
access-list remote_site3 permit ip host 10.10.10.1 172.16.99.1 255.255.255.255
Jeremy correct me if I am wrong,
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 184.108.40.206 to access the service.
Customer B, you will use 220.127.116.11 to access the service.
Customer C, you will use 18.104.22.168 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.
Let's say you NAT'd the internal service as follows:
static (inside,outside) 192.168.10.20 172.16.25.20 netmask 255.255.255.255
... and there are no other translations in the firewall.
Then Customer A says, "I cannot route to 192.168.10.20" because I am using the 192.168.10.0/24 network internally. Well..., you can't change the static because Customer Z is using 192.168.10.20 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 (172.16.25.20) to a different address, one that Customer A can route to, through a conditional static!
static (inside,outside) 192.168.10.20 172.16.25.20 netmask 255.255.255.255 <--- The existing global static
static (inside,outside) 22.214.171.124 access-list customer_A_acl <---- The new conditional static
access-list customer_A_acl permit ip host 172.16.25.20 126.96.36.199 255.255.255.0
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).