ASA 9.2(2)4 vs 8.2(5)26 inter-interface routing

[pekka.tamminen]

Hello,

we are migrating networks from our old ASA to new one. We have problem with security levels and enabling traffic between same security levels.

I have situation where I have 10+ customers in same FW and mostly same security level.

Nameifs

- Customer1-LAN

- Customer2-LAN
- Customer2-VDI
- Customer2-DMZ

- Customer3-LAN
- Customer3-VDI

- Customer4-LAN

etc.

Dynamic NAT:

Customer1-LAN, Outside dynamic interface

ACL:

implicit rules: Any less secure networks

Old FW configuration clients wasn't able to access other customer networks. That was configured with nat exemptions and no nat-control. Without nat exepmtion connection was not established with "portmap translation creation failed" error.

But newer FW Customers could access each other when inter-interface routing is enabled and no nat exempt done.

Any suggestions to deal this problem? Customers would need to communicate with own networks and internet.

[Jouni Forss · Accepted solution]

Hi / Moi,

I personally never used NAT or "security-level" to control traffic and Cisco suggests not using NAT for this purpose. Atleast they used to at some point.

I would personally configure each interface with ACL

• Create an "object-group" that contains a specific customers subnets (naturally one for each customer)
• Create an "object-group" that contains all Private Ranges/Networks
• Configure an ACL that first allows all traffic to the other subnets of the same customer by using the created "object-group" in the rule
• Continue by blocking all other traffic towards other Private Ranges/Networks again using the other "object-group" you created.
• Finally allow all other traffic by using the destination address "any" (This rule would basically allow the Internet traffic as you have blocked all Private Ranges previously)

The above should achieve allowing only traffic between same Customers subnets and at the same time preventing all traffic between customers. Naturally you will have to configure ACL for each interface but it really only takes effort in the start and gives you more control than "security-level" value which really does not give any options.

Naturally you might have to make small adjustments to the above listed thing. You might have public subnets in the Customers networks behind the firewall. This would mean adding those subnets in both "object-group" that you create so the Customer could access its own public subnets but others could not. Otherwise the last "any" rule would allow this traffic as it would only block Private Ranges before this addition.

You might also want to configure the rules between same customers subnets more specifically. I mean you might not want to allow all TCP/UDP traffic so you would have to make the start of the ACL a bit more bigger depending on your need.

Hope this helps :)

- Jouni

[Jouni Forss]

Just to add regarding NAT,

If all of your customers use the same shared public IP addess as Dynamic PAT address towards Internet then you can achieve the Dynamic PAT with a single command in the new software

nat (any,outside) after-auto source dynamic any interface

If you need to use different IP address than the "interface" then you will need to create an "object" for that IP address.

If other customers need other public PAT IP addresses then you should naturally configure the above command by specifying the source interface name instead of the "any" that's there in the above command.

- Jouni

[pekka.tamminen]

Thank you for your answers. This works like expected.

[Dinesh Moudgil]

Hi pekka.tamminen,

PART A:
By default , communication between different interfaces that have the same security level is denied.

This is enabled via :
same-security-traffic permit inter-interface

You can disable this if you do not wish to allow such communication.

PART B:

Couple of things to confirm:

If you remove nat control prior to upgrade, then there would not be much difference in working of the firewalls from nat perspective.

If you do not remove nat control prior to upgrade , then it will create nat rules to allow the traffic between interfaces which look like these:

object network obj_any
   subnet 0.0.0.0 0.0.0.0
   nat (inside,outside) dynamic obj-0.0.0.0
object network obj-0.0.0.0
   host 0.0.0.0
object network obj_any-01
   subnet 0.0.0.0 0.0.0.0
   nat (inside,mgmt) dynamic obj-0.0.0.0

If you do not wish to use natting to determine the traffic flow and just wish to leverage access-list,
then it is recommended that you should issue no nat-control prior to upgrading to ASA version 8.3.

You can probably remove the above natting rules if you forgot to remove nat-control command.

Here is a document for your reference:-
https://supportforums.cisco.com/document/48646/asa-83-upgrade-what-you-need-know#Remove_nat-control_from_your_ASA_Configuration

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.