Policy NAT

[Bruce Summers]

Hi,

I need a little assistance here...I'm trying to do multiple nats...The intent is to nat traffic inbound to isolated/non-routable vlans to the vlan interface to give the appearance the traffic is within the same subnet to keep a couple hundred servers from having to have static routes placed on them....

I presently do this with traffic from vlan 701 and 702 to vlan 760 and 770...

However, I have a further requirement to nat a single address coming out of vlan 760 to the vlan interface for vlan 770.  but, i have not been able to get this to function...and i'm not entirely sure that i can get it to work...below is the configs/info i'm working with...I removed the configs i have tried to use...

Goal:  nat a single address, to the inteface of vlan 770 interface ONLY when traffic is destined for vlan 770 without breaking any of the other natting.

nat (Out_of_Band_Server_Mgmt) 1 access-list inside
nat (EBM_SVCS_2) 1 access-list PNAT702

global (Enterprise_Backup_and_Mgmt) 1 interface
global (Enterprise_Backup_and_Mgmt_2) 1 interface

access-list PNAT702 extended permit ip 10.76.169.0 255.255.255.0 192.168.213.0 255.255.255.0
access-list PNAT702 extended permit icmp 10.76.169.0 255.255.255.0 192.168.213.0 255.255.255.0

access-list inside extended permit icmp any any
access-list inside extended permit ip any any

interface Vlan701                10.76.168.1
nameif Out_of_Band_Server_Mgmt

interface Vlan702                10.76.169.1
nameif EBM_SVCS_2

interface Vlan760                 192.168.212.1
nameif Enterprise_Backup_and_Mgmt

interface Vlan770                  192.168.213.1
nameif Enterprise_Backup_and_Mgmt_2
.

[Jennifer Halim]

I wouldn't think there will be any problem with running DHCP server on FWSM especially just with 150 addresses.

I saw more problem with DHCP relay feature on FWSM.

Here is more information on DHCP server on FWSM for your reference:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/ip_f.html#wp1041659

[Bruce Summers]

Good deal...

I'll use the argument that "cisco tac" says go for it...lol...

[Jennifer Halim]

Ooops

Ex TAC you mean

[Bruce Summers]

I knew what I meant

They wont know...lol...

Thanks again, and when I blow that config onto that firewall, I'll post

the results and award some points...

Thanks

[Bruce Summers]

alright

one more question, if you don't mind...just advise more than anything...

[Jennifer Halim]

Sure, feel free to ask.

[Bruce Summers]

What is the best method for clearing out old ACL's...

I've looked at possibly removing hitcnt=0 acl's, but I don't necessarily

trust that...reson being:

Acl = IP address ---> subnet /24

Access-list test extended permit ip Host 10.10.10.1 10.10.2.0

255.255.255.0 eq 135

This might show a hitcnt=0 on 10.10.2.0, but I'm concerned that

potentially an address within that /24 (ie...10.10.2.35) might have had

a hit that doesn't show when you "sho access-list test"...

I don't know if that concern is unfounded or not...

[Jennifer Halim]

Is the access-list named "test" actually applied anywhere?

Since the name of the access-list is test, I am assuming that someone configured that for testing purposes (perhaps during a packet capture?).

If you perform: sh run | i test

You should see if access-list named "test" is actually applied anywhere within the configuration. If it is not, then you are save to completely remove access-list "test".

Otherwise, if it is actually applied to an interface, then i would suggest that you actually monitor the access-list for a couple of weeks before removing it straight away (unless you are sure that that line of access-list has been there for a while).

[Bruce Summers]

I'm sorry...i was using "test" as an example...i have many many acls' with hitcnt=0 that I would like to blow away, but not real comfortable...

I was just looking to see if there is some method that you may have used in the past for removing acl's without breaking everything in the process...some way to determine if they're used or not...

Again, the only thing I'm familiar with is the use of looking for hitcnt=0 acl's...

[Jennifer Halim]

Actually, you are absolutely right. That is the only method that I normally use to determine whether the access-list is in use or not.

For all new connections, it will have to hit the access-list prior to it being allowed through, and will be logged in the hitcount. So yes, that's the method that is normally used to identify inactive access-list.

Further to that, sometimes, people also keep a snapshot of the existing hit count, and for example: there is 10 hitcount in 1 particular access-list and after monitoring it for a few weeks, it is still at 10, it is likely that the access-list might not be used anymore. I would monitor it for a month at least if you are free.

Worst comes to worst, for sure someone will complain when the traffic is failing to connect, but so far, the above method is pretty accurate.

[Bruce Summers]

Thank you again for your advice...

I will probably give that nat a try either Thursday or Friday...I'll post here when I've made the change...

Now one additional thing about the natting...looking at it, it seems it should have no baring on any other natting that is being performed specific to any of the interfaces that we discussed, that is correct?

[Jennifer Halim]

Assuming that you don't have any other NAT statement applied for interface: Enterprise_Backup_and_Mgmt_2 then the answer is yes, it shouldn't affect any other NATing on those interfaces.