08-19-2010 05:26 PM - edited 03-04-2019 09:29 AM
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 20.20.20.1 netmask 255.255.255.255
static (inside,vendor2) 10.10.10.1 30.30.30.1 netmask 255.255.255.255
static (inside,vendor3) 10.10.10.1 40.40.40.1 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)
Thanks
08-19-2010 05:56 PM
Hello,
That would work. The only thing is you got the addresses reversed. Correct format would be:
static (inside,vendor1) 20.20.20.1 10.10.10.1 netmask 255.255.255.255
static (inside,vendor2) 30.30.30.1 10.10.10.1 netmask 255.255.255.255
static (inside,vendor3) 40.40.40.1 10.10.10.1 netmask 255.255.255.255
Hope this helps.
Regards,
NT
08-20-2010 07:57 AM
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) 20.20.20.1 access-list remote_site1
static (inside,outside) 30.30.30.1 access-list remote_site2
static (inside,outside) 40.40.40.1 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).
End result:
Traffic inbound or outbound from 172.16.83.0/24 will hit 20.20.20.1 to access 10.10.10.1
Traffic inbound or outbound from 192.168.54.0/24 will hit 30.30.30.1 to access 10.10.10.1
Traffic inbound or outbound from 172.16.99.0/24 will hit 40.40.40.1 to access 10.10.10.1
Jeremy
08-20-2010 08:51 AM
Jeremy,
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 10.10.10.1, theres will be 20.20.20.1
If my internal ip is 10.10.10.2, theres will be 20.20.20.2
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.
08-20-2010 09:52 AM
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 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,
Manish.
08-23-2010 09:03 AM
David/Manish,
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 20.20.20.1 to access the service.
Customer B, you will use 30.30.30.1 to access the service.
Customer C, you will use 40.40.40.1 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) 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) 20.20.20.1 access-list customer_A_acl <---- The new conditional static
access-list customer_A_acl permit ip host 172.16.25.20 208.25.36.0 255.255.255.0
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).
Thanks,
-Jeremy
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide