same-security-traffic permit inter-interface not working

Answered Question
Jun 5th, 2008

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...

I have this problem too.
0 votes
Correct Answer by srue about 8 years 6 months ago

access-list nat0_acl permit 172.19.21.0 255.255.255.0 172.19.20.0 255.255.255.0

nat (insidevoice) 0 access-list nat0_acl

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.8 (4 ratings)
Loading.
Farrukh Haroon Thu, 06/05/2008 - 11:12

Which version are you running, is nat-control off or on?

show run nat-control

Regards

Farrukh

brianbono Thu, 06/05/2008 - 11:18

nat-control is not enabled and I am running 7.0 (7)

what could be missing?

srue Thu, 06/05/2008 - 11:25

Do you have any nat statements (dynamic or static) between those two interfaces?

Farrukh Haroon Thu, 06/05/2008 - 11:28

Just run the packet-tracer command, it should tell you whats going wrong. If possible post the output here.

assuming you are going from inside1 to inside2

inside1 = 136.1.1.0 /25

inside2 = 136.1.2.0 /25

packet-tracer input inside1 tcp 136.1.1.3

11005 136.1.2.100 80 detailed

Regards

Farrukh

brianbono Thu, 06/05/2008 - 11:39

part of my config below:

interface Ethernet0/0

nameif outside

security-level 0

ip address 123.123.123.2 255.255.255.24

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 172.19.20.40 255.255.255.0

!

interface Ethernet0/2

nameif insidevoice

security-level 100

ip address 172.19.21.40 255.255.255.0

same-security-traffic permit inter-interface

access-list outside_access_in extended permit icmp any any

access-list outside_access_in_V1 extended permit icmp any 172.19.21.0 255.255.255.0

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

nat (insidevoice) 1 0.0.0.0 0.0.0.0

access-group outside_access_in_V1 in interface outside

route outside 0.0.0.0 0.0.0.0 123.123.123.1 1

also, im confused because I cant seem to connect to the internet if I am on the insidevoice network.

Please help.

brianbono Thu, 06/05/2008 - 11:53

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 192.168.100.0 255.255.255.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.25.0.0 255.255.0.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.22.0.0 255.255.0.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 192.0.0.0 255.255.255.0

access-list tozzz extended permit ip 172.19.20.0 255.255.255.0 172.25.0.0 255.255.0.0

access-list toxxx extended permit ip 172.19.20.0 255.255.255.0 172.22.0.0 255.255.0.0

access-list toccc extended permit ip 172.19.20.0 255.255.255.0 192.0.0.0 255.255.255.0

access-list qw extended permit ip 172.19.20.0 255.255.255.0 172.19.200.0 255.255.255.0

access-list qw extended permit ip 172.19.200.0 255.255.255.0 172.19.20.0 255.255.255.0

access-list outside_access_in_V1 extended permit icmp any 172.19.21.0 255.255.255.0

Farrukh Haroon Thu, 06/05/2008 - 12:18

Ok first of all, for 'inside' to communicate with 'insidevoice', you need to add the following line in your nonat ACL

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.19.21.0 255.255.0.0

Or if you want to NAT/PAT this traffic, something like

global (insidevoice) 1 interface

Once you enable any sort of dynamic NAT / PAT, 'no nat-control' rule no longer applies for that zone, now all traffic between this zone and any other zone either requires NAT rules or NAT exemption.

As to why insidevoice cannot access Internet, please run the packet-tracer command I gave you before, it seems OK to me....

Regards

Farrukh

brianbono Thu, 06/05/2008 - 12:29

tried to add the suggested:

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.19.21.0 255.255.255.0

but still I cant communicate with the other VLAN.

Appreciate all your help... any other suggestions?

Farrukh Haroon Thu, 06/05/2008 - 12:30

yes. packet-tracer with the 'detailed' keyword:)

Also make sure you do a 'clear local-host' and 'clear xlate' after making any NAT changes.

Regards

Farrukh

brianbono Fri, 06/06/2008 - 01:41

I just ran some debugs and this was one of the things that caught my eye:

No translation group found for icmp src inside:172.19.20.19 dst insidevoice:172.19.21.21 (type 8, code 0)

what do i need to add on NAT to make sure 172.19.20.x can communicate to 172.19.21.x considering both have the same security level and that the "same-security-traffic permit inter-interface" is already enabled yet I can't communicate...

please advise..

Farrukh Haroon Fri, 06/06/2008 - 02:53

As I mentioned before, you can use:

Ok first of all, for 'inside' to communicate with 'insidevoice', you need to add the following line in your nonat ACL

(NAT Exemption):

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.19.21.0 255.255.255.0 (I gave wrong mask earlier)

Or if you want to NAT/PAT this traffic, something like

(Dynamic NAT):

global (insidevoice) 1 interface

You can also use:

(Identity Static)

static (inside,insidevoice) 172.19.20.0 172.19.20.0 netmask 255.255.255.0

Try any three, if one does not work for some reason (which is strange, try the other).

BTW, why don't you post packet-tracer output? You have something personal against the command? This is *THIRD TIME* I'm requesting you to do it......

packter-tracer input inside icmp 172.19.20.19 8 0 172.19.21.21 detailed

See even Cisco is using it, it won't hurt :)

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080734db7.shtml

Regards

Farrukh

srue Fri, 06/06/2008 - 04:50

Once you enable dynamic nat on one of those interfaces, it's as if the same-security traffic command wasn't even entered because of the nat. In your case, the ASA is behaving as expected.

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

however, you do need to configure nat rules if you define dynamic NAT for either of the same-security level interfaces.

brianbono Fri, 06/06/2008 - 04:52

I have tried your three suggested solutions but to no avail. I have also tried the packet-tracer but had this error:

ASA# packet-tracer input inside icmp 172.19.20.19 8 0 172.19.21.21 detailed

packet-tracer input inside icmp 172.19.20.19 8 0 172.19.21.21 detailed

^

ERROR: % Invalid input detected at '^' marker.

I got this log for the ASA below:

3|Jun 06 2008 02:34:40|305005: No translation group found for icmp src inside:172.19.20.19 dst insidevoice:172.19.21.21 (type 8, code 0)

Please help...

appreciate all your help Farrukh :)

husycisco Fri, 06/06/2008 - 05:15

Hi Brian

Run "clear xlate" after applying NAT statements.

Please post your full sanitized config and let us see.

Regards

Farrukh Haroon Fri, 06/06/2008 - 05:17

Hrm, are you running ASA 7.2.x or higher? packet-tracer is only supported on 7.2(1) and later?

Regards

Farrukh

srue Fri, 06/06/2008 - 05:53

the OP is running 7.0(7).

he needs to post a sanitized config at this point so we can see everythign that's going on.

brianbono Fri, 06/06/2008 - 05:54

ASA# sh run

: Saved

:

ASA Version 7.0(7)

!

hostname ASA

domain-name abc.com

names

dns-guard

!

interface Ethernet0/0

nameif outside

security-level 0

ip address 123.123.123.2 255.255.255.240

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 172.19.20.40 255.255.255.0

!

interface Ethernet0/2

nameif insidevoice

security-level 100

ip address 172.19.21.40 255.255.255.0

!

interface Management0/0

shutdown

no nameif

no security-level

no ip address

management-only

!

ftp mode passive

same-security-traffic permit inter-interface

access-list outside_access_in extended permit icmp any any

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 192.168.100.0 255.255.255.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.25.0.0 255.255.0.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.22.0.0 255.255.0.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 192.0.0.0 255.255.255.0

access-list nonat extended permit ip 172.19.20.0 255.255.255.0 172.19.21.0 255.255.255.0

access-list to1 extended permit ip 172.19.20.0 255.255.255.0 172.25.0.0 255.255.0.0

access-list to2 extended permit ip 172.19.20.0 255.255.255.0 172.22.0.0 255.255.0.0

access-list to3 extended permit ip 172.19.20.0 255.255.255.0 192.0.0.0 255.255.255.0

access-list to4 extended permit ip 172.19.20.0 255.255.255.0 172.19.200.0 255.255.255.0

access-list to5 extended permit ip 172.19.200.0 255.255.255.0 172.19.20.0 255.255.255.0

pager lines 24

logging asdm informational

mtu outside 1500

mtu inside 1500

mtu insidevoice 1500

ip local pool vpnip 172.19.200.10-172.19.200.250

asdm image disk0:/asdm-507.bin

no asdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

nat (insidevoice) 1 0.0.0.0 0.0.0.0

route outside 0.0.0.0 0.0.0.0 123.123.123.1 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server VPNAuth protocol radius

aaa-server VPNAuth host 172.19.20.250

key xxxxx

group-policy ABC internal

group-policy ABC attributes

dns-server value 172.19.20.250

vpn-idle-timeout 30

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ST

default-domain value ABC.local

webvpn

http server enable

http 0.0.0.0 0.0.0.0 outside

http 172.19.20.0 255.255.255.0 inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

telnet 172.19.20.0 255.255.255.0 inside

telnet timeout 60

ssh 0.0.0.0 0.0.0.0 outside

ssh timeout 60

console timeout 0

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

inspect tftp

!

service-policy global_policy global

: end

ASA#

srue Fri, 06/06/2008 - 06:02

put a nat 0 statement on insidevoice using an ACL, which will match traffic going from insidevoice to inside.

and if you want to ping, either create ACL's to allow echo/echo reply, or add icmp inspection.

brianbono Fri, 06/06/2008 - 06:09

can you post the sample config to be added? so that i could try it out... thank you very much

Correct Answer
srue Fri, 06/06/2008 - 06:12

access-list nat0_acl permit 172.19.21.0 255.255.255.0 172.19.20.0 255.255.255.0

nat (insidevoice) 0 access-list nat0_acl

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

brianbono Fri, 06/06/2008 - 06:35

got this error again:

ASA(config)# access-list nat0_acl permit 172.19.21.0 255.255.255.0 172.19.$

access-list nat0_acl permit 172.19.21.0 255.255.255.0 172.19.20.0 255.255.255.0

^

ERROR: % Invalid input detected at '^' marker.

sorry of being such a pain in the @$%#$^% :) thanks man

srue Fri, 06/06/2008 - 06:43

woops..

i was just testing him..yeah that's it. it was a test.

brianbono Fri, 06/06/2008 - 06:57

I don't care if it was a test or not... the thing is that it's working hehehe

husycisco Fri, 06/06/2008 - 07:10

Here is what I think :)

If you have an exempt NAT statement applied to interface inside and contains source as inside and destination as dmz, this effects traffic originated from both inside and dmz. I mean once you apply correct exempt NAT to inside that will take care of bot inside->dmz and dmz->inside. You dont need one applied to dmz.

Then how did it resolve the issue? Here are my theories.

1) Brian was testing the connectivity with ping which is not a good way when it is a firewall device that sees ICMP a possible dos attack and denies by default. And brian's outside_access_in ACL which permits ICMP was not applied to outside interface with access-group command. ICMP inspection did the trick. But this theory can not explain the translation error logs

2) Brian was hitting CSCsd90140 or another one which prevented inside exempt nat to operate correctly. An exempt nat applied to dmz interface, which is actually not necessary under normal circumstances, did operate normally and did what inside exempt nat couldnt.

Any thoughts?

But glad that issue is resolved.

srue Fri, 06/06/2008 - 07:15

I posted this earlier:

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

however, you do need to configure nat rules if you define dynamic NAT for either of the same-security level interfaces.

that problem was the nat (insidevoice) 1 statement...which was needed..because of that, you need nat 0 statements on both itnerfaces. and yes, icmp is not good for testing, unless you've allowed it through the firewall.

Farrukh Haroon Fri, 06/06/2008 - 07:15

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

husycisco Fri, 06/06/2008 - 07:18

"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?

husycisco Fri, 06/06/2008 - 07:23

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

husycisco Fri, 06/06/2008 - 07:30

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

husycisco Fri, 06/06/2008 - 07:33

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 Fri, 06/06/2008 - 07:39

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

husycisco Fri, 06/06/2008 - 07:44

No, identity nat as Cisco explains

static (inside,dmz) insidenetwork insidenetwork netmask insidenetworkmask

Ok let me try it and post back.

brianbono Fri, 06/06/2008 - 07:36

"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...

husycisco Fri, 06/06/2008 - 08:17

"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

Attachment: 
Farrukh Haroon Fri, 06/06/2008 - 12:44

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

husycisco Fri, 06/06/2008 - 17:19

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 Fri, 06/06/2008 - 17:56

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

husycisco Fri, 06/06/2008 - 19:13

" 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 Fri, 06/06/2008 - 21:26

Yes buddy I told you even before the tests that:

I agree 100% with you :)

Regards

Farrukh

Actions

This Discussion