01-12-2004 03:42 PM - edited 02-20-2020 11:11 PM
I have an application where I need to restrict inside users going to particular PIX port but do not want to restrict network management users. For the sake of the example, the 172.16 subnet is the main user community and the 172.31 subnet is the network management group's subnet.
global (eth0) 1 interface
global (eth2) 1 interface
nat (inside) 1 172.16.0.0 255.255.0.0
nat (inside) 1 172.31.0.0 255.255.0.0
Now I need to carve out some users for a specific application on interface eth3 and want to allow the whole 172.31 subnet access as well so I try the following:
global (eth3) 1 interface
nat (inside) 2 172.16.1.33 255.255.255.255
nat (inside) 2 172.16.1.34 255.255.255.255
nat (inside) 2 172.16.1.35 255.255.255.255
nat (inside) 2 172.16.1.36 255.255.255.255
So far so good but then I add the following and get the error "Duplicate NAT entry":
nat (inside) 2 172.31.0.0 255.255.0.0
What's up with that? I know I have options to get around it. One of which appears to be splitting up the subnet (I know I can code the following but have not tested to see if it actually works properly):
nat (inside) 2 172.31.0.0 255.255.128.0
nat (inside) 2 172.31.128.0 255.255.128.0
Is it wrong to have overlapping address ranges in different NAT groups on the same interface? If so, why? If not, am I getting this message? Is it due to a bug in 6.3(1) code? Thanks in advance.
01-13-2004 07:55 AM
hello
I think that configuring object-groups with different access priviledges may be more helpfull.
Outside of that , yes overlapping subnets may render you problems , rules of routing apply here .
and finnaly I dont think that the problem is a bug.
Contract with a profesional if your network resources are crucial and security is a real concern
William Ferrell
IA WAN Eng., CCNP, CISSP
01-13-2004 03:34 PM
You cannot have redundant [nat] statements on the same interface because the Pix would have no way to determine which one to place the devices in.
In your example, the global (interface) 2 group only exists on your eth3 interface, so there doesn't seem to be a conflict. However, the same global ()2 could be created on the outside, thus creating the decision problem for the Pix.
Try this:
nat (inside) 1 172.16.0.0 255.240.0.0 [covers all internally networks including 172.31.0.0]
global (outside) 1 interface
nat (inside) 2 172.31.0.0 255.255.0.0
nat (inside) 2 172.16.1.33 255.255.255.255
nat (inside) 2 172.16.1.34 255.255.255.255
nat (inside) 2 172.16.1.35 255.255.255.255
nat (inside) 2 172.16.1.36 255.255.255.255
global (eth3) 2 interface
If you don't really need to NAT the inside hosts going out to eth3, you could also use [nat 0] and an access-list to say which traffic was allowed to bypass NAT. If the app server is 10.10.10.10 you could use:
access-l no-nat-inside permit ip 172.31.0.0 255.255.0.0 host 10.10.10.10
access-list no-nat-inside permit ip host 172.16.1.33 host 10.10.10.10
nat (inside) 0 access-list no-nat-inside
Traffic not defined in the ACL would not be able to go out to the eth3 interface because no NAT would be avaiable to them.
Also, you could just say that all hosts could NAT out to eth3, and you use a similiar ACL on the inside interface to deny all accept the allowed hosts.
In either of the last two cases, an object-group could be used to manage the allowed hosts so that a single ACL entry would represent all allowed hosts.
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