Официален блог на WebEKM EKM очаквайте сайта онлайн скоро.
Download Free Templates http://bigtheme.net/ free full Wordpress, Joomla, Mgento - premium themes.
Cisco ASA with Multiple Context – Firewall Virtualization
Multiple Context on ASA provides the highest level of virtualization, within one single chassis we get 2 virtual firewalls. Each with separate Data and Control Plane. Idea similar to VRF but in Multiple Context we may share one interface between 2 contexts what makes its more sophisticated.
Let’s have a look on the below diagram to better understand how Multiple Context works:
As we see, on the “outside” interface we assigned 2 IP addresses that belong to 2 different contexts.
When do we want to use Multiple Context ? For instance if we want to seperate administration tasks. We may appoint 2 different administrators for 2 different departaments, each departament will be a separate context on the same firewall.
If we want to check what mode the firewall works on, we have to type “show mode“.
There are a few steps that we have to pass through, before we apply fully working multiple context:
1 We have to make conversion from “single mode” to “multiple mode“. We make it with “mode multiple” command. After that, ASA will reboot itself. After the reboot we get SYSTEM CONFIG – that care about our contexts. SYSTEM CONFIG has knowledge ONLY about: names of contexts that are running on the ASA, config URLs assigned to the contexts (may be keept locally on the flash or remotly on FTP server) and interfaces assigned to the particular contexts.
2 Previous running-config is being copied as an old_running-config.
3 One new context is being created which is called “admin context” and configuration from running-config is being copied to this context, so we retain interfaces, modular policy framework, NAT, even RA VPN sessions (but only from version 9.5.2) etc., so traffic that is going through the ASA will be forwarded and nothing gets changed from the users behind the ASA point of view. The conifg file for “admin context” is called “admin.cfg”. Important thing : the admin role from “admin context” may provide any changes regarding contexts and delete them. There can only be 1 context that has the role of admin at a time. One of the contexts must have assigned the role of admin! The context with the admin role is marked with “*” asterisk next to the name.
4 Then we may create next contexts and work with them.
5 Contexts and ASDM. We may manage the other context only from the admin context, if we change the admin role to different context we will lose connectivity with ASA via ASDM
So let’s try to deploy multiple context !
Here is our LAB topology
“class default” with limits that we see, provides limitation for particular connections, we also see config-url for admin.cfg. If we want, we may create our own class with limits and assign particular contexts to its.
2 Let’s create another contexts with command “context [NAME]“. I created 2 contexts cxt-1 and cxt-2. I also created config files for them with command “config-url disk0:/cxt-1.cfg” and “config-url disk0:/cxt-2.cfg“”. “Show context” command shows us all contexts
4 And assigned this class to contexts ctx-1 and ctx-2. I also allocated interfaces to contexts with new names that will be visible under, “cxt_1_outside” for example. Pay attention, interface GigabitEthernet0 is being shared between 2 contexts. If you didn’t “up” interfaces under “system config” first , then they will be unvisible for the other contexts! Then you have to get back to “system config” and “up” given interfaces, before you assign them to contexts
5 Now, when we run the command “show context” we gonna see below output. As we see admin context plays the admin role (the asterisk). If we want to change it, we use command “admin-context [NAME_OF_NEW_ADMIN_CONTEXT]”
6 Let’s also check how interfaces looks
Now ASA with the contexts is ready to go and to further configuration. From now on we may configure interfaces under particular context, we have to remember we don’t use names like “gigabiethernet2” anymore only “ctx_2_outside”. If we want to change the context we use command “changeto context [NAME]“. If we want to get back to SYSTEM CONFIG and admin context we use command “changeto system“. If we want to remove any context we use “no context [name]“.
7 Let’s assign IP addresses to the particular interfaces
We see that for 2 outside addresses on the same interface in 2 different context we have the same MAC address. This is definitely what we would like to avoid otherwise, the returning traffic never gets the initiating host in “Inside” zone. Remember: always change MAC addresses on shared interfaces. 2 different IP addresses with the same MAC address is never good idea! Let’s change MAC address for interface “cxt_1_outside” in context cxt-1
8 The last thing that I would like to show you is deployment of NAT, we make it on particular contexts. Of course first you have to add static default route to the both contexts “route OUTSIDE 0.0.0.0 0.0.0.0 192.168.1.250“
Now you should be able to ping let’s say 8.8.8.8 address from the INSIDE hosts ! If not, check MPF on both contexts (policy-map global_policy) if “icmp inspection” has been added.