same-security-traffic permit inter-interface not working

[brianbono]

Guys, need help to allow traffic between two interfaces that have the same security level. I have already enabled the "same-security-traffic permit inter-interface" command but still i cant ping my switch or server on the other vlan...

what else do i need to do to accomplish this task? ACL are on defaults as of now...

[Farrukh Haroon]

Exactly, I agree 100% that NAT 0 ACL is bi-directional. After all this is the major difference between 'Identity NAT' and 'NAT Exemption :). Oh well its working now thats great.

At least I have two points..lolz

Regards

Farrukh

[Alan Huseyin Kayahan]

"By default, you do not need to do NAT between same-security level interfaces, even if nat-control is enabled."

Thats %100 correct

"that problem was the nat (insidevoice) 1 statement...which was needed..because of that, you need nat 0 statements on both itnerfaces"

I dont agree with that statement. Can you please explain?

[Alan Huseyin Kayahan]

oh wait, nat (insidevoice) 1 0 0 exists? then you are correct Steven!

[Alan Huseyin Kayahan]

Umm wait, I just tested this and disproofed myself :) So I am back to my previous conclusion. I dont agree with another nat exempt statement to dmz interface although a translation group is applied to that interface

[Alan Huseyin Kayahan]

Farrukh,

"After all this is the major difference between 'Identity NAT' and 'NAT Exemption "

And here is a shocker for you :) I removed the exempt nat, and added identity nat, ran cl xlate, and traffic can still be established in a bi-directional fashion. Only the return traffic should supposed to be flowing in identity NAT correct?

My test platform is ASA 525 IOS 7.2(2)

Any thoughts?

[Farrukh Haroon]

by identity nat you mean:

nat 0 (without the ACL) right?

Also just try do do both clear local-host and clear xlate (just in case). Or even a "clear local-host all" (even tough 'all' is for firewall terminated sessions)

Regards

Farrukh

[Alan Huseyin Kayahan]

No, identity nat as Cisco explains

static (inside,dmz) insidenetwork insidenetwork netmask insidenetworkmask

Ok let me try it and post back.

[brianbono]

"ICMP inspection did the trick" i did not included the:

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

after I have added the:

access-list nat0_acl permit ip 172.19.21.0 255.255.255.0 172.19.20.0 255.255.255.0

nat (insidevoice) 0 access-list nat0_acl

IT WORKED...

i'm not to sure if if i still need this one below:

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.19.21.0 255.255.255.0

finally it worked! thank you very much guys... keep on posting as I am trying to understand what really happened...

[Alan Huseyin Kayahan]

"ICMP inspection did the trick" i did not included the:

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

Theory 1 is down. It could explain the syslog message either. So your IOS is bugged.

My lab and test results (Packet tracer for single interface exempt nat and identity nat) are attached into lab.txt

Please comment.

Regards

[Farrukh Haroon]

I'm sorry I was out of my house :)

See you are confusing 'Identity Nat' with 'Identity Static'/'Identity Static NAT'. Look at the following link for differences between the three, 'Identity NAT' [nat 0 ip mask] is the only one that is uni-directional. 'NAT Exemption' [Nat 0 ACL] and 'Identity Static' [static (a,b) same-ip same-ip] BOTH are bi-directional. So what you are seeing is the desired behavior.

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/cfgnat.html#wp1042530

Regards

Farrukh

[Alan Huseyin Kayahan]

Farrukh,

Great article. But you know what? Close to no one arrives at that conclusion if Cisco havent specifically expressed "Identity NAT" and "Identity Static NAT", since applying an ACL (a Policy) makes the statement "Conditional". You assign conditions, to narrow down the criterias to match for having desired output. But in this occasion, assigning an ACL to the same statement, same command, completely adds a new feature. Anyway, its great to discuss.

Did you have time to check my lab output for that nat issue? What do you think?

Regards

[Farrukh Haroon]

I don't understand your first concern in the file about the NAT RPF check, it seems normal to me, what exactly are you thinking is wrong/strange there, please clarify.

The un-NAT bit goes like this,

static (inside,dmz) 172.16.5.0 172.16.5.0 netmask 255.255.255.0

You can say that the 'actual flow' of this command is from inside >> dmz where the Source IPs are modified. Everytime this rule is matched in the inside >> dmz direction, you will see a 'Translate' hit count.

Everytime the flow is in the opposite direction, i.e. from the dmz >> inside where the destination is modifed, you will see a 'Un-Translate' hit count. I hope this clarifies the second issue. Its not 'Un-Translate' in the strict literal sense.

Regards

Farrukh

[Alan Huseyin Kayahan]

" don't understand your first concern in the file about the NAT RPF check, it seems normal to me"

It seems normal for sure, what I wanted to state there is, an exempt nat statement is not needed in DMZ. As seen in config, there is no exempt nat statement in dmz, there is a NAT translation group 1, scenario is all same with Brian's issue, and exempt NAT in inside is enough unlike the recommendation by Steven which seems to resolve the issue.

[Farrukh Haroon]

Yes buddy I told you even before the tests that:

I agree 100% with you :)

Regards

Farrukh