Need help with NAT

[mjsully]

I have a firewall that is configured to not translate anything from the inside 10.0.0.0 network when going out one of my DMZ interfaces. Config looks like this:

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.255

however, I now need to make an exception. I have a group of servers on the inside that have 10.x.x.x addresses, but I need them to translate to a single 10.15.x.x address when leaving the inside interface and going out through the dmz. Can this work as I have the whole 10.0.0.0 range translating to itself? Or do I have to translate the group of servers into something other than a 10.x.x.x address?

[lgijssel]

The static as you have it now is not required. You could try the following approach:

access-list nonat deny

access-list nonat permit 10.0.0.0 255.0.0.0

access-list 101 permit

global (DMZ) 5 10.15.x.x

nat (inside) 0 access-list nonat

nat (inside) 5 access-list 101

This should result in not-natting all traffic except the List 101 matches all of the and performs nat in the standard way.

Regards,

Leo

[mjsully]

That would fix the issue, but the problem is that I am working with a live production network that already has the static (inside,dmz) 10.0.0.0 10.0.0.0 255.0.0.0 in place. I can't mess with it. Is there any other way?

[lgijssel]

In that case the best practice is to test the change in a test-environment and implement it afterwards.

That would be advisable for this case anyway as you will have to make quite some changes.

The alternative is to make the change during off-hours. Don't come with the eternal no downtime argument. If this config is so darn important the owner must have facilities to test changes, if not it is probably not that important after all! ;-|

Regards,

Leo

[mjsully]

I am trying your config on a lab pix with this config in place:

access-list no_nat deny ip host 10.1.1.1 host 10.15.x.x

access-list no_nat permit ip any interface dmz

access-list 101 permit ip host 10.1.1.1 host 10.15.x.x

nat (inside) 0 access-list no_nat

nat (inside) 5 access-list 101

global (dmz) 5 10.25.1.1

I'm assuming I remove the static statment:

static (inside,dmz) 10.0.0.0 10.0.0.0 nm 255.0.0.0

when I do that I get PAT'd correctly when connecting from the 10.1.1.1 address, However, any other inside address is not able to get out and I see the error "no translation group" found when looking at the logs. There are no hits on the last line of the above no_nat acl.

So I tried modifying the last line in the no_nat acl from this to this:

access-list no_nat permit ip any interface dmz

changed to

access-list no_nat permit ip any any

After doing this, it was working for all hosts. But the problem is on the live PIX I have several interfaces. If I leave "any any" on the no_nat, it will apply to all interfaces. Only the inside to dmz interface should generally not be nat'd (with the exception of these servers). Leaving the config on this will hose all the translations I have for the other interfaces. Why is not using the acl when pointing to the destination interface?

[lgijssel]

This was supposed tyo be a partial config. How do you get out? I suppose via the outside interface.

The acl nonat should only match source and destination for the DMZ so that everything else is not affected.

I used the nat (inside) with index 5 while I assumed that you were using other indexes for nat towards the Internet and that kind of stuff.

[mjsully]

the outside interface goes to vpn router where our vpn's terminate. If I specify "any" as the destination address of what not to NAT, it will kill all the static translations I have between that outside interface and our inside hosts. I don't understand why the permit section in my no_nat acl doesn't work if I specify traffic going out the dmz interface, versus "any".

[m.mohanasundaram]

Hi,

Two things I observed.

1. The access-list referrenced in the "nat 0" command should have only 'permit' statements.

2. The nat order of operation; nat 0 takes precedence over nat 5 statement.

See the PIX Command Reference for more info:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/mr.htm#wp1032129

Mo