The document discusses Cisco ASA firewall contexts, which allow virtualizing a single physical ASA device to act as multiple independent firewalls. Some key points: - Contexts have their own routing, filtering, and address translation rules within an ASA in either routing or transparent mode. - Features like VPN, dynamic routing, and QoS are not supported in contexts. Contexts are used when multiple security appliances are needed on one device. - The system context manages interface allocation and other settings for all contexts. The admin context provides system-level access. Normal contexts are user-defined partitions. - Physical interfaces can be allocated to contexts. Contexts also have resource limits defined through resource classes to

1. ASA/PIX Multiple Context
Done By: Tariq Bader – CCIE # 35627
1

2. INTRODUCTION
2

3. Introduction
• ASA firewall supports software virtualization,
by means of so-called firewall contexts.
• Every context has its own set of routing,
filtering/inspection and address translation
rules.
• All contexts must be in either routing or
transparent firewall mode – you cannot mix
modes in different contexts.
3

4. Introduction
• Supported Features:
– Only static routing
– Firewall features
– IPS
– Management
• Unsupported Features
– VPN termination
– Dynamic Routing Protocol
– QoS
4

5. Introduction
Where do we use Multiple context?
– In ISPs, were they sell security services to many customers,
they implement a cost-effective, space saving solution.
– Large Enterprises who keeps their departments completely
separated.
– Basically, we use multiple context whenever there is a
network that requires more than one security appliance.
Note: The multiple context feature is not supported on
the ASA 5505 Series Adaptive Security Appliance.
5

6. CONTEXT TYPES
6

7. Context Types
• System Context
• Admin Context
• Normal Context
7

8. System Context
• The System administrator adds and manages contexts by
the configuration of each context configuration location,
allocated interfaces, and other context operational
parameters in the system configuration.
• The system configuration identifies basic settings for the
security appliance. You cannot assign any IP addresses
when you are under the system context, with exception to
the management interface.
• You can upgrade or downgrade the PIX/ASA software only
in the System EXEC mode, not in the other context modes.
8

9. Admin Context
• The admin context is like any other context, except that when a user logs
in to the admin context, that user will have system administrator rights,
and can access the system and all other contexts
• Admin context configuration must reside on the Flash memory.
• If you convert from a Single mode to the Multiple Context mode, the
admin context is created automatically and the configuration file will be
created on the flash memory
• This context could be combined with any regular user context or be
dedicated.
• Note: Admin context (when it is dedicated) is not counted in the context
license. For example, if you get the license for two contexts, you are
allowed to have the admin context and two other contexts.
9

10. Normal Context
• Is the actual partitioned firewall.
• Contexts can be accessed via Console, Telnet,
SSH, and ASDM
• If you log in to an non-admin context, you can
only access the configuration for that context
10

11. CONFIGURATION
11

12. Configuration
Note: The ports on
the switch that are
connected to ASA
must be in trunk
mode since
multiple VLAN
traffic has to travel
through it once the
ASA interfaces are
broken into
sub−interfaces.
12

13. Configuration
• In order to turn the firewall to the multiple
contexts mode, you should enter the command
mode multiple when logged via the console port.
• Note: You may do this remotely but you risk
losing connection to the box.
• This will force mode change to multiple and
reload the appliance.
• If you connect to the appliance the console port,
you are logging into the system context after the
reload.
13

14. Configuration
• When you convert from single mode to multiple mode, the
security appliance converts the running configuration into
two files:
1. New startup configuration that comprises the system
configuration.
2. 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.“
14

15. Configuration Steps
• You should to do the following things while
logged into the system context:
1) Configure physical interfaces. You need to un-
shutdown the interfaces that you want to
allocate to the contexts. If you are creating sub-
interfaces using VLANs, you should do it under
the system context as well.
15

16. Configuration Steps
2) Define the admin context.
• This is a special context that allows logging in the
firewall remotely (via ssh, telnet or https).
• This context should be configured first as the
firewall won’t let you create any other contexts
prior to designating the admin context using the
global command admin-context <NAME>.
• As we have said this context is automatically
created When you convert from the single-
context mode.
16

17. Configuration Steps
3) Define additional contexts if needed and allocate
physical interfaces to the contexts.
• Use the command allocate-interface <Physical-
Interface> [<Iface-Name>] under the context
configuration mode for interface allocation.
• Here <Physical-Interface> is the physical interface or
sub-interface name and <Iface-Name> is the name that
the context sees for this interface.
• Using this command you can hide the real interface
names from the context administrators (e.g. hide VLAN
numbers), in order to provide additional level of
isolation from the physical configuration.
17

18. Configuration Steps
4) Change to the context configuration, and
proceed as usual.
• Assign interface names, security levels and IP
addresses.
• Set up static routes for subnets not directly connected
to the context – even for the subnets connected to
another contexts.
18

19. Configuration Notes
• Every configured context should have a configuration URL defined using the command
config-url <PATH> to store its configuration. Without this command, the context
configuration is incomplete.
• After the context has been defined, you may switch to the “in-context” configuration using
the command changeto context <NAME>.
• In order to access the system context remotely, you should log into the admin context using
any configured remote access method and issue the command changeto system.
• Enter the allocate−interface command(s) before you enter the config−url command. The
security appliance must assign interfaces to the context before it loads the context
configuration; the context configuration can include commands that refer to interfaces
(interface, nat, global...). If you enter the config−url command first, the security appliance
loads the context configuration immediately. If the context contains any commands that refer
to interfaces, those commands fail.
• Use the command write memory all in the system context to save all contexts configuration
on the persistent storage. You may also save configuration for a context individually when
logged under the particular context using the command write memory.
19

20. Configuration Notes
• Physical interfaces could be shared among contexts,
i.e. you may assign the same interface to different
contexts.
• Interface sharing is the unique feature of the ASA
firewall contexts, and this is what makes it stand apart
from IOS VRF technology.erface to different contexts.
• When an interface is shared between two contexts,
certain classification rules should be applied to
determine which context the incoming packets should
use.
20

21. Configuration Notes
• If there is a shared physical interface between the contexts, each context
could generally have different IP and MAC addresses on this interface.
• It is possible to share the IP address as well, though. If you want to assign
the same IP address to the shared interfaces in multiple context mode
you’ll need to give the logical interfaces a separate MAC address.
• You may use non-overlapping subnets or simply different IPs on the same
subnet.
• By default both contexts will inherit the same MAC address from the
shared physical interface. This might result in the firewall not being able to
classify the incoming traffic properly.
• Use the command mac-address auto in the system context to
automatically generate a MAC address for every new “virtual” interface.
21

22. Configuration
In order to enable multiple mode, enter this command:
hostname(config)# mode multiple
You are prompted to reboot the security appliance.
CiscoASA(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
!
The old running configuration file will be written to flash
The admin context configuration will be written to flash
The new running configuration file was written to flash
Security context mode: multiple
***
*** −−− SHUTDOWN NOW −−−
***
*** Message to all terminals:
***
*** change mode
Rebooting....
22

23. Configuration
• Creating a new context:
Ciscoasa(config)# Context ContextA
Ciscoasa(config-ctx)# description text
Ciscoasa(config-ctx)# Allocate-interface
<Physical_interface> [mapped name]
Ciscoasa(config-ctx)# Config-url url
• You can’t rename the context, you will have to delete it,
then create a new one with the new name.
– Delete a Context:
No context ContextA
23

24. Example Scenario
24

25. FIREWALL CONTEXTS ROUTING
25

26. Firewall Context Routing
• As mentioned previously, in the multiple-
context mode the firewall supports only static
routing.
• you need to configure a static route for every
non-directly connected subnet for a firewall
context or set up a static default route.
• All adjacent routers should be also configured
with static routes to allow for full connectivity.
26

27. Firewall Context Routing
• Routing between contexts:
– firewall contexts do not share IP routing tables,
and thus if you want to establish communications
between the routing contexts you need either of
the following:
1. Configure each context with a set of static routes for
the subnets connected or located behind the other
context.
2. Use an external router that has full knowledge of the
subnets behind each of the contexts to provide
connectivity.
27

28. Firewall Context Routing
• Context Cascading
– Recall that physical interfaces could be shared
between the contexts.
– In some scenarios, you may even configure the
same physical interface as the inside for one
context and outside for another. This is called
context cascading. *Look at the figure below:
28

29. FIREWALL CONTEXTS
CLASSIFICATION
29

30. Firewall Contexts Classification
• It is easy to assign an input packet to the
context if the interface where it has been
received is uniquely allocated to the context.
• If the interface is shared, additional rules are
needed.
30

31. Firewall Contexts Classification
• Shared interfaces classification rules:
1) The firewall looks at the destination MAC address of the
packet – the destination MAC designated the “next-hop” for
the packet.*
2) If the MAC address is the same in both contexts for the same
interface, the firewall attempts to use NAT configuration in
every context to resolve the “conflicts”.
• This may happen if you intentionally assign the same IP address to
both contexts or did not assign different MAC addresses to the
shared interfaces.
• The firewall attempts to match the destination IP address and
TCP/UDP port information in the packet with the active translation
slots in every context. The context with the matching translation slot is
selected as the target context.
• This type of classification allows sharing the same IP subnet or even IP
address on the shared interface.
• You are not required to have unique MAC addresses in each context,
as the translation slots are used for traffic classification.
31

32. Firewall Contexts Classification
• Shared interfaces classification rules:
3) If all contexts on the shared interface use the
same IP address/MAC then you cannot access
the contexts on the shared interface.
• Why? Because for traffic destined to the firewall itself,
it classifies based on the destination IP address.
• So it is generally recommended to use separate IP
addresses (MAC could be the same) on the shared
interfaces.
32

33. RESOURCE MANAGEMENT
33

34. Resource Management
• The firewall has limited resources, shared
between the contexts.
• The resources include concurrent connections,
inspections, translation slots, management
sessions (telnet, ssh and https) number of inside
hosts and so on.
• Some of those resources are limited based on the
licensing option – e.g. the number of inside hosts.
Others are limited by the firewall hardware.
34

35. Resource Management
• In order to avoid resource contention and exhaustion,
the firewall allows limiting per-context resources using
the resource class concept.
• Every class specifies the amount of resource available
to a context. Classes are assigned to the contexts to
enforce the limits.
• By default, all contexts are assigned class “default”.
• Note that contexts do not “share” the particular class
resources. They only inherit the resource limits set by a
class.
35

36. Resource Management
• When you create a new class, it inherits all
limits from the “default” resource class.
• When you re-define any particular limit in the
new class, you automatically override the
default setting for this limit.
• You may also configure the default class
settings and all classes will inherit these
values, unless they redefine them.
36

37. Resource Management
37

38. Resource Management
• The appliance never “reserves” any resources for classes. It
simply uses them to compute the resource limits and
satisfies any request that is within the limit for a given class.
• For example, suppose the system supports up to 1000
connection maximum, and you create new class with the
limit of 500 connections. You assign this class to 3 contexts.
At the peak of their usage every context may request up to
500 connections, exceeding the total limit of 1000. Thus it
is up to the administrator to properly set limits and prevent
resource starvation.
• You may set resource limits in absolute values (e.g. number
of connections or hosts) or in percent's of the maximum
resource available.
38

39. Resource Management
• The syntax is:
class <NAME>
limit-resource <Resource> [<Value>|{1-100%}]
– Some resources, like Conns, Inspects and Syslogs
support rate limiting, using the command:
limit-resource rate [{Conns|Inspects|Syslogs}|{1-100%}]
39

40. Q&A
40