Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Multiple NAT Groups With Same Source on Same PIX Interface

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.

2 REPLIES
New Member

Re: Multiple NAT Groups With Same Source on Same PIX Interface

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

http://www.waizcomm-pcnets.net/

Silver

Re: Multiple NAT Groups With Same Source on Same PIX Interface

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.

288
Views
0
Helpful
2
Replies
CreatePlease login to create content