topic Re: ASA- Multi-Context Shared Interface Packet Classifier in Network Security

ASA- Multi-Context Shared Interface Packet Classifier

riedmueller — Mon, 11 Mar 2019 18:36:25 GMT

I'm trying to get my head wrapped around the multi-context packet classifier used by the ASA when a shared outside interface is used. Below is what I think I think (props to Peter King at Sports Illustrated); could someone please point out the errors in my understanding?

What I've boiled it down to is that the edge router and the ASA are using a shared network on the shared interface

When unique MACs ARE allowed (ASA)

1) The router receives a frame destined for a host on that shared network, which is actually an inside global address on the ASA.

2) The router performs the ARP and gets the MAC address for that IP, which is actually the custom MAC, and sends the frame toward the ASA

3) The classifier receives and then passes the frame to the appropriate context based on the MAC address

4) From there the CONTEXT instance references it's NAT config and ACL rules to identify and allow/disallow the traffic to pass into the network.

When unique MAC addresses can't be used and we have to classify based on destination IP address (e.g. with the FWSM),

1) The router receives a frame destined for a host on that shared network, which is actually an inside global address on the ASA.

2) The router performs the ARP and gets the MAC address for that IP, which is physical interface BIA, and sends the frame toward the ASA

3) The classifier receives the frame and then has to look at each context's configuration to find a matching static or global command. Once it finds that, it passes the frame/packet to the appropriate context

4) From there the CONTEXT instance references it's NAT config and ACL rules to identify and allow/disallow the traffic to pass into the network.

So the big difference in the two (mac-address destination versus ip address destination) is that the classifier has to look further into each context configuration to figure out which context gets the packet/frame when a unique MAC can't be used. (additional question : Is it safe to consider the classifier in this case as the admin context or the system space when it's performing this search for a matching NAT statement...is it a system process or a context process?)

Many thanks

Jim

Re: ASA- Multi-Context Shared Interface Packet Classifier

sachinga.hcl — Tue, 07 Sep 2010 20:16:02 GMT

Hi jim,

There are two ways to set up multiple security contexts:

Multiple contexts in Routed mode (supports Shared Interface)
Multiple contexts in Transparent mode (does not support Shared Interface)

Each packet that enters the security appliance must be classified, so that the security appliance can determine to which context to send a packet. It is very important in case two security contexts share one physical interface.

Unique Interfaces

If only one context is associated with the ingress interface, the security appliance classifies the packet into that context. In transparent firewall mode, unique interfaces for contexts are required, so this method is used to classify packets at all times.

Unique MAC Addresses

If multiple contexts share an interface, then the classifier uses the interface MAC address. The security appliance lets you assign a different MAC address in each context to the same shared interface, whether it is a shared physical interface or a shared subinterface. By default, shared interfaces do not have unique MAC addresses; the interface uses the physical interface burned-in MAC address in every context. An upstream router cannot route directly to a context without unique MAC addresses. You can set the MAC addresses manually when you configure each interface, or you can automatically generate MAC addresses using mac-address auto command.

NAT Configuration

If you do not have unique MAC addresses, then the classifier intercepts the packet and performs a destination IP address lookup. All other fields are ignored; only the destination IP address is used. To use the destination address for classification, the classifier must have knowledge about the subnets located behind each security context. The classifier relies on the NAT configuration to determine the subnets in each context. The classifier matches the destination IP address to either a static command or a global command. In the case of the global command, the classifier does not need a matching nat command or an active NAT session to classify the packet. Whether the packet can communicate with the destination IP address after classification depends on how you configure NAT and NAT control.

If you share an inside interface and do not use unique MAC addresses, the classifier imposes some major restrictions. The classifier relies on the address translation configuration to classify the packet within a context, and you must translate the destination addresses of the traffic. Because you do not usually perform NAT on outside addresses, sending packets from inside to outside on a shared interface is not always possible; the outside network is large, (the Web, for example), and addresses are not predictable for an outside NAT configuration. If you share an inside interface, I suggest you to use unique MAC addresses.

Enabling Multiple Context Mode

The context mode (single or multiple) is not stored in the configuration file, even though it does endure reboots. If you need to copy your configuration to another device, set the mode on the new device to match using the mode command.

When you convert from single mode to multiple mode, the security appliance converts the running configuration into two files: a new startup configuration that comprises the system configuration, and admin.cfg that comprises the admin context (in the root directory of the internal Flash memory). The original running configuration is saved as old_running.cfg (in the root directory of the internal Flash memory). The original startup configuration is not saved. The security appliance automatically adds an entry for the admin context to the system configuration with the name admin.

To enable multiple mode, enter command mode multiple. You are prompted to reboot the security appliance.

VLAN Interfaces

For each VLAN to pass traffic, you need to configure an interface name (the nameif command), and for routed mode, an IP address. You should also change the security level from the default, which is 0. If you name an interface inside and you do not set the security level explicitly, then the adaptive security appliance sets the security level to 100.

To configure a VLAN interface, specify the VLAN ID on the subinterface (ex. f0/0.1) using command vlan number, where the number is between 1 and 1001.

For further reading in this regard:

http://etherealmind.com/cisco-fwsm-configuration-design-trap-advice-help/

https://learningnetwork.cisco.com/thread/9864

http://www.ciscopress.com/articles/article.asp?p=426641

http://www.cisco.com/en/US/docs/security/asa/asa71/configuration/guide/contexts.html

http://www.mail-archive.com/ccie_security@onlinestudylist.com/msg02474.html

HTH

Sachin Garg

Message was edited by: sachinga.hcl

Re: ASA- Multi-Context Shared Interface Packet Classifier

riedmueller — Wed, 08 Sep 2010 12:08:39 GMT

Thanks!

I'm in an opposite situation,

pascalfr0 — Mon, 24 Aug 2015 09:14:07 GMT

I'm in an opposite situation, where I need to share an "inside" interface on a ASA5520.

Security context 1 + Security Context 2 => shared interface ge0/0 => LAN with a bigip cluster using auto-last-hop for retrun traffic.

Obviously I need to set different MAC addresses for each context, and different IP adresses also.

Is it supported to use a shared interface for the inside connection ?

Is my "projected" configuration correct (different MAC and IP @ for each context ??).

Pascal