Multi-Tenant Firewall and Same-Security Subinterfaces IOS 9.0

[jtadamofod81]

Hello All,

I'm so accustomed to < 8.3 and am having great difficulty getting an environment working properly so I'm now going to leverage the Cisco community!

We are setting up a network with customers behind a pair of 5510s.  All of these customers will have their own dedicated subinterface in their own vlan.  Out of the gate I had the same-security permit inter-interface and all networks could communicate with each other.  I definitely don't want this, so I disabled that command and now each customer network is unable to communicate with each other as planned.

The issue now lies in networks where a customer have 2 separate VLANs (let say a staging and a prod environment) where they need to communicate.  Is this doable if they are in the same-security level and same-security permit inter-interface is disabled?  Would I just need to create an ACL for the networks to talk?  Is there a better way of doing this with same-security permit inter-interface enabled?

Pre 8.3 I would have same-security permit inter-interface enabled, but traffic couldn't talk to the other interface unless I created a NAT exemption and ACL.  Do I still create a NAT exemption?

[Jouni Forss · Accepted solution]

Hi,

The base problem you are running with the different software levels is the "nat-control" setting which exists in 8.2 (and earlier) but doesnt exist in 8.3 (and later) versions of the ASA software.

In the 8.2 and pre software you had the change with the "nat-control" configuration to require a connection to have a NAT configuration for it to be able to pass traffic through the ASA. Naturally this coupled with the "security-level" gave you more changes to control traffic without resorting to ACL.

However in the new 8.3 and later software level the "nat-control" doesnt exist anymore and wether a connection has a NAT configuration that be applied to it or not the ASA still allows the connection (provided other ASA checks allow it) So basically you wont need any NAT configurations between your local interface. The most common NAT configurations should be between your local interface and the "outside" interface of the ASA.

If you try to control the traffic between interfaces with the global  configuration commands you mention, you will possibly be constantly  "juggling" around with the "security-level" configurations so that the  correct rules for the traffic is applied.

This question has appeared on these forums every now and then and I basically always suggest the same approach which is to configure an ACL on EVERY interface of the ASA.

• Consider leaving the "same-security-traffic" configurations on the ASA. This is because even though you might have interface ACLs allowing traffic, if they for some reason are left with identical "security-level" the ACL wont be enough to allow the traffic.
• Configure each interface an ACL
• As a first step to configure the ACL create an "object-group" that will contain EVERY network behind your firewalls local interface (except the "outside" ofcourse)
• Use this "object-group" in EACH interface ACL beginning to BLOCK ALL traffic from behind that interface towards these networks
• After this allow or block different Internet/Out -bound traffic like usual
• In the even 2 (or more) networks behind different interfaces need to communicate between eachother configure an allowing statement in the beginning of each ACL. The already existing "deny" statement with the "object-group" will already make sure that rest of the traffic between the networks get blocked

As a very simple example you could consider the following

Networks:

• LAN1: 10.10.10.0/24
• LAN2: 10.10.20.0/24
• DMZ1: 192.168.100.0/24
• DMZ2: 192.168.200.0/24

same-security-traffic permit inter-interface

Interface GigabitEthernet0/0

description Trunk

interface GigabitEthernet0/0.10

vlan 10

nameif LAN1

security-level 100

ip address 10.10.10.1 255.255.255.0

interface GigabitEthernet0/0.20

vlan 20

nameif LAN2

security-level 100

ip address 10.10.20.1 255.255.255.0

interface GigabitEthernet0/0.100

vlan 100

nameif DMZ1

security-level 100

ip address 192.168.100.1 255.255.255.0

interface GigabitEthernet0/0.200

vlan 200

nameif DMZ2

security-level 100

ip address 192.168.200.1 255.255.255.0

object-group network BLOCK-LOCAL-NETWORKS

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 192.168.10.0 255.255.255.0

network-object 192.168.20.0 255.255.255.0

access-list LAN1-IN remark Allow HTTP / HTTPS to DMZ1 server

access-list LAN1-IN permit tcp 10.10.10.0 255.255.0 host 192.168.100.100 eq www

access-list LAN1-IN permit tcp 10.10.10.0 255.255.0 host 192.168.100.100 eq https

access-list LAN1-IN remark Block traffic to any other local network

access-list LAN1-IN deny ip any object-group BLOCK-LOCAL-NETWORKS

access-list LAN1-IN remark Allow all other outbound traffic

access-list LAN1-IN permit ip 10.10.10.0 255.255.255.0 any

access-group LAN1-IN in interface LAN1

And naturally all the other ACLs would follow the same pattern in one form or another. You wouldnt really have to worry about traffic being allowed between the interfaces but rather the most work would probably be adding "permit" statements in the top of each ACL when required for inter-interface communication. But I would imagine the amount of those additions would also stay at a manageable level for the FW admins.

Naturally in the largest environments you would probably want to get a higher end ASA and virtualize it and separate each customer environment to their own Security Context where you would avoid this situation alltogether. Naturally the biggest points against this solution usually might be costs and the fact that virtualizing the ASA to Multiple Contex Mode disables some essential operationality of the ASA, of which the most commonly important is probably VPN Client connections (L2L VPN is supported in 9.x software in Multiple Context Mode)

Hope this helps

Please remember to mark the reply as the correct answer if it answered your question. And/or rate helpfull answers

Ask more if need

- Jouni

[jtadamofod81]

Thanks so much for the thorough answer Jouni.

I guess I'm just surprised that there isn't a more elegant solution than creating a huge ACL for each subinterface.  Just curious that because we'd be applying the ACL to each subinterface, wouldn't we have to create an object-group for each customer?  The ACL you showed as an example has the source network (10.10.10.0) in the block-local-networks.

object-group network BLOCK-LOCAL-NETWORKS

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 192.168.10.0 255.255.255.0

network-object 192.168.20.0 255.255.255.0

access-list LAN1-IN deny ip any object-group BLOCK-LOCAL-NETWORKS

Wouldn't that block the local network in LAN1?

[Jouni Forss]

Hi,

In the case that you see as a possible problem we have to notice how the network routing/traffic forwarding works.

If we consider that one ASA interface holds the 10.10.10.0/24 network and the host inside that network communicate with eachother then they will NEVER use the ASA to connect to eachother. Hosts that are directly connected in the same network simply send a broadcast ARP to determine the MAC address of the other hosts IP address and when they get a reply from that host they will finally connect directly to that host and the traffic would never pass through or show on the ASA. The only thing the ASA could see is the ARP broadcast.

One thing to lookout related to that ARP broadcast though, is the fact that you have to disable Proxy ARP on the the LAN interface holding 10.10.10.0/24 gateway. (sysopt noproxyarp LAN1) If you dont, the ASA might reply to the ARP broadcast even though it doesnt own the IP address. This sometimes poses problems in the LAN hosts connectivity to eachother when the Proxy ARP is enabled. (not having the above command enabled)

So as you can see, you can use the same "object-group" for each interface ACL which in turn makes the managing of the ACLs a lot easier. You simply add networks when a new interface/network has been added to the ASA to the same "object-group" and build the basic ACL for the interface or add "permit" rules to an existing ACL.(If you have multiple networks behind some router behind an interface that already has an ACL)

Hope this clarifys things

Remember to rate helpfull answers And thank you for marking the reply as the correct answer.

- Jouni

[Jouni Forss]

Actually there might be another option, but generally I dont use it myself.

Starting from software level 8.3(1) you have been able to configure a Global Access-list

What you essentially do here is that you configure a single ACL that when applied with the keyword "global" controls traffic from every single interface in the inbound direction.

Sure, you will end up with a single ACL that contains EVERYTHING related to passing traffic through the ASA that mainly makes it something that I dont want to try. (Coupled with the fact that I have been used to the interface based ACLs from the start since no other form were supported on the Cisco firewalls before this, to my understanding atleast)

Naturally this means that you will only have a single ACL line that has the "object-group" defining all the networks but you will also have every single interfaces ACLs rules in the same ACL.

If I were ever to try this sort of ACL configurationg I would always do it through CLI (as I do anyway) and I would use the "remark" ACL configuration parameter to insert several lines of "remark" texts between sections where one interfaces rules start and the others end. Otherwise it would simply be PAINFULL to watch through the CLI or to make anything out of it.

But as people have different preferences I thought I'd mention about it incase you were interested.

One thing to note also. You can use interface based ACLs together with Global ACLs. In those cases the interface based ACL to my understanding is gone through first.

I havent thought through the above setup. Just thinking if it could give any solutions to existing problematic situations when creating ACLs on the ASA in special environments.

Hope thishelps

- Jouni