Cannot Communicate Between Same Security Level Interfaces - PIX 535 - PIX OS 8.0.4.28

[Richard H. Shores]

Hi!

I have a PIX 535 running PIX OS 8.0.4.28 and I am trying to implement same security level (level 100) between two PIX interfaces. One range of subnets is coming from a Catalyst 3560G with IP routing and CIDR subnetting in another area and another Catalyst 3560G with IP routing CIDR subnetting coming from another area to the PIX on different interfaces, using a non-switchport connection. I have the same-security-traffic permit inter-interface command and statics statement for both subnet ranges. I still cannot ping, etc from one subnet to the other. I have EIGRP routing set up on the two switches and the PIX and I can do an sh ip route on the switches and sh route on the PIX and the subnets are all there. I have used Packet Tracer inside of ASDM and it stops on a default deny

Here is the subnetting:

Switch A:

10.10.10.0/26 Classless        255.255.255.248        0.0.0.7        10.10.10.1   to   10.10.10.6      

10.10.10.8/26 Classless        255.255.255.248        0.0.0.7        10.10.10.9   to   10.10.10.14       

10.10.10.16/26 Classless      255.255.255.248        0.0.0.7        10.10.10.17  to   10.10.10.22       

10.10.10.24/26 Classless      255.255.255.248        0.0.0.7        10.10.10.25  to   10.10.10.30      

10.10.10.32/26 Classless      255.255.255.248        0.0.0.7        10.10.10.33  to   10.10.10.38  

Switch B:

172.16.10.0/30 Classless        255.255.255.252       0.0.0.3      172.16.10.1   to   172.16.10.2

172.16.20.0/27 Classless        255.255.255.224        0.0.0.31    172.16.20.1   to   172.16.20.30    

172.16.30.0/28 Classless        255.255.255.240        0.0.0.15    172.16.30.1   to   172.16.30.14    

172.16.40.0/27 Classless        255.255.255.224        0.0.0.31    172.16.40.1   to   172.16.40.30       

172.16.50.0/29 Classless        255.255.255.248        0.0.0.7      172.16.50.1   to   172.16.50.6 

Interface IP's

inside     10.10.10.1 255.255.255.248

inside-2  172.16.10.1 255.255.255.252

I realize that the PIX is a firewall and not a router. I would rather not have to purchase a router, but if there is no way the same security levels will work, I guess I will have to do so.

Thanks for any input or suggestions.

Richard

[Dinkar Sharma]

Hi Richard,

You can use the following commands to achieve the required purpose.

same-security-traffic permit intra-interface (to allow U-turining traffic)

same-security-traffic permit inter-interface (for communication between inside and inside-2 having same security level)

<>In your case you need the second command to make it work.

Thanks and Regards,

Dinkar

[juan-ruiz · Accepted solution]

Hi Richard,

You may already have this in place but I thought I would ask are you nating between interfaces and if you are have you exempted the nating from inside to inside-2?

Also do you have any ACL on inside and inside-2 that are not in place that may prevent it from communicating?

Can you please show us your static statements please?

If I wanted my inside interface 10.10.10.0 255.255.255.0 to talk to inside-2 interface 172.16.0.0 255.255.0.0 on the firewall I do not need to u-turn and a static statement like this would work (inside,inside-2) 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

but if you want inside to talk to inside-2 and both networks are off the same interface then you need to u-turn so you will need the same-security-traffic permit intra-interface and make sure your inside interface does not have any ACL that would block the traffic and you may also need an ACL to bypass TCP traffic applied to a class map and a policy map to by-pass TCP. I always try to route at the switch to reduce any u-turn for routing clear text traffic but on the VPN it works like a charm.

[Richard H. Shores]

Thank you Dinkar and Juan,

My original configuration with the static identity NAT

(inside,inside-2) 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

(inside-2,inside) 172.16.0.0 255.255.0.0 172.16.0.0 255.255.0.0

would not work because I have NAT in place to go to the outside. Juan's question about the NAT exemption got me thinking. I decided to do some more digging on the Cisco web site and found the answer to my problem...use an access list and NAT 0:

access-list inside_nonat extended permit ip 172.16.0.0 255.255.0.0 10.10.10.0 255.255.255.0

access-list inside-2_nonat extended permit ip 10.10.10.0 255.255.255.0 172.16.0.0 255.255.0.0

nat (inside) 0 access-list inside_nonat

After changing to the access list and NAT 0, everything is working fine.

Thanka againf for your help!

Richard