Tuesday, February 25, 2014

Cisco ASA multi-context & 10 tips and tricks from socpuppet

Running multi-contexts on the cisco ASA firewall can be both fun and challenging at the same time.

Here's an example of a pair of ASA in multi-context modes



This is also known simple as any of the following;   Virtual Firewall, Multi_Tenants, or Partitioning a firewall appliances.


Both PaloAlto, Juniper, & Fortinet over similar capabilities within their hardware appliances along with a few others vendors.

NOTE/: Multi-context mode is the ONLY way you can run a cisco firewall pair  in a Active-Active state. This means both units are processing data for at least 2 or more contexts.  


The number of contexts you have will be directly effected by the license you have purchased for the units. Based on the models and resources, it's not uncommon to have 5 or more contexts.

There's a lot of advantages that exists with running  multi-contexts on a cisco ASA;
  •       a possible reduced number of firewall units to manage
  •       ease with audits and management-access-controls
  •       reduce power and interfaces requirements
  •       better fail-over management
  •       a possible reductions in  TOC and number of licenses to buy
  •       quick and rapid deployment  for new deployments & without the delay of buying another pair of firewalls
  •       centralize management to a pair of firewall units verse  having multi firewall hardware   appliances

Here's a few tip/tricks that I have learned over the courses of 7 years with playing around with multi-contexts.


1: During your initials design & plans, think out your context strategy down to the naming convention and address before you engage. This includes  802.1q tagging and vlan ###s. It very hard to rename or change contexts after they are initially built and have objects tied to the contexts.

2: You can't re-use the pre-defined  context named "admin",  unless  you rename  the existing context "admin". I find it's easier to avoid using any  pre-existing context names like admin or system.

But you sometimes will run across the stubborn directors and security engineers that insist on creating more work , by reusing predefined context names. Try to avoid this!




3: A L3-addresses interface can be part of only one context, but  with the exception that you can share a interface within 2 or more contexts. Each L3 address interfaces that shares the same  real or virtual interface, " will need a unique l2 address for proper classification of packets within a flow ".

4: I find it best and with regards to the above  #3,  to define  your L2  unique address per interfaces and not to rely on auto mac assignments

( aka mac-address )
 
e.g

interface Port-channel10.3
 description Mycontext2 outside "mac-address 00a0.c900.0002 +0004"
 mac-address 00a0.c900.0002 standby 00a0.c900.0004 <--------HERE
 nameif EXTERNAL02
 security-level 0
 ip address 192.0.2.1 255.255.255.0 standby 192.0.2.2
 ospf authentication-key *****
 ospf authentication
!




and


interface Port-channel10.3
 description Mycontext2 outside "mac-address 00a0.c900.0001 +0003"
 mac-address 00a0.c900.0001 standby 00a0.c900.0003  <----HERE
 nameif EXTERNAL02
 security-level 0
 ip address 192.0.2.3 255.255.255.0 standby 192.0.2.4
 ospf authentication-key *****
 ospf authentication
!



5:  Be cautious of the context that your accessing &  when making firewall rules changes. This a common mistaken with newbies and when reviewing and deploying policies.

6: Don't make changes on the standby context. I know this should be clear, but I'll mention that the  ACTIVE unit syncs it's config to the standby unit.

If you unaware of the context status and if the  unit is active or not, the ASA will provide a simple warning ;

**** WARNING ****
    Configuration Replication is NOT performed from Standby unit to Active unit.
    Configurations are no longer synchronized.


7: Like wise if your diagnosing something, beware of the context status ACTIVE or STANDBY.

This includes things such as monitoring  Connection and XLATE tables,  or  performing basic diagnostic commands like ping, traceroute, packet-tracer. Do it within the context that's active.


NOTE: Keep in mind that the stand-by units that run dynamic routing protocols , will not process or have routing updates installed in it's RIB.


If  your are monitoring/diagnostics any of these above actions executed from the stand-by context, will misguided and steered you down the wrong path, which can results in; " wasted time or improper corrective actions taken "

8: When executing the failover command,  be aware of what contexts are active and if it's on the primary or secondary unit.

 Issue  the  show failover state ( from  system context ) to help identify the current failover state. It's output is help and quickly shows you what unit your on and what contexts are active to not, and if  the failover link is active or not.

note: you can't failover a  context  or failover-group as it's called in  cisco, to a unit that's not showing 100% failover status  available

9: If you do a packet-tracer, and see the following output;

Result:
input-interface: inside-testing
input-status: up
input-line-status: up
Action: drop
Drop-reason: (ifc-classify) Virtual firewall classification failed  <-----HERE


This means that you executed the  packet trace from the standby context.

10: Remember to not delete any configuration files on the compact flash disk. This where your context startup-configurations files resides  & that you defined earlier when you built the contexts under the system context.

e.g ( for example only )


admin.cfg
MYcontext1.cfg
MYcontext2.cf


Directory of disk0:/

24     drwx  32768        14:24:18 Apr 22 2013  coredumpinfo
71     -rwx  5003         13:19:16 Dec 17 2013  oldconfig_2013Dec17_1221.cfg
72     drwx  32768        06:40:52 Aug 27 2013  tmp
11     drwx  32768        14:29:52 Apr 22 2013  log
22     drwx  32768        20:37:18 Jan 07 2014  crypto_archive
74     -rwx  18097844     06:26:06 Aug 27 2013  asdm-713.bin
75     -rwx  12998641     14:30:46 Apr 22 2013  csd_3.5.2008-k9.pkg
76     drwx  32768        14:30:48 Apr 22 2013  sdesktop
77     -rwx  6487517      14:30:48 Apr 22 2013  anyconnect-macosx-i386-2.5.2014-k9.pkg
78     -rwx  6689498      14:30:48 Apr 22 2013  anyconnect-linux-2.5.2014-k9.pkg
79     -rwx  4678691      14:30:48 Apr 22 2013  anyconnect-win-2.5.2014-k9.pkg
80     -rwx  22388        10:59:13 Feb 24 2014  MYcontext1.cfg <<<<<-HERE
23     drwx  32768        05:12:36 Oct 21 2013  snmp
81     -rwx  37767168     13:26:10 Dec 17 2013  asa914-smp-k8.bin
82     -rwx  22834188     13:30:00 Dec 17 2013  asdm-715.bin
83     -rwx  249705       12:26:34 Jan 08 2014  crash.txt
84     -rwx  38191104     06:27:56 Aug 27 2013  asa912-smp-k8.bin
85     -rwx  4312         06:32:06 Aug 27 2013  8_2_5_0_startup_cfg.sav
86     -rwx  1138         06:32:08 Aug 27 2013  upgrade_startup_errors_201308270532.log
87     -rwx  4885         10:18:48 Sep 25 2013  old_running.cfg
88     -rwx  12863        10:57:12 Feb 24 2014  admin.cfg    <<<<-HERE
89     -rwx  21161        10:55:51 Feb 14 2014  MYcontext2.cfg   <<<<<-HERE
90     -rwx  37656576     09:56:22 Oct 07 2013  asa913-smp-k8.bin



11: Remember  that context names are case sensitive;

e.g

act/FW1(config)# context Admin
WARNING: Context names are case sensitive.  This context is called
    'Admin', but there is also a context called 'admin'.
INFO: Enter 'no context Admin', if you want to remove this context.
Creating context 'Admin'... Done. (7)
act/MAFW1(config-ctx)# no context Admin



NOTE:  the name  Admin , ADMIN  and admin , are not the same. The same with Mycontext1 vrs MYcontext1.


12: Changing from a single mode context to  a multi-mode context or from multi-mode back to a single mode, will  require a reboot.

Back up your configs!


13: Configs are sync'd between  PRIMARY And SECONDARY units for the firewall, but images files are not syncronized between the 2. So a software upgrade will require to copy the images files to both unit.


14:

IPS or other security modules configurations are NOT syncronized between primary & secondary units. This include IPS software and licenses.


15: Remote-Access VPNs ( IPSEC/SSL ) , are  not support as of the this post within any cisco ASA codeset as of 9.1.4  ( possible  available in the future  per cisco )
 
16: If you stacked contexts on top of another context,  be aware of traffic flow and policies. A policy might be required in both contexts for traffic to enter or exit.

e.g (  a example of a  stacked context aka cascade contexts  with one in front of another )



17: If your in a MSSP/ISP it's always best to apply some type of resource limits & per each customer context to avoid one customer from exhausting the  resources.

class default
  limit-resource All 0
  limit-resource Mac-addresses 65535
  limit-resource ASDM 5
  limit-resource SSH 5
  limit-resource Telnet 5
  limit-resource Xlates 100000
  limit-resource VPN Other 5
  limit-resource VPN IKEv1 in-negotiation 5.0%
!

class Admin-class
  limit-resource Routes 60
  limit-resource Telnet 1
  limit-resource ASDM 5.0%
  limit-resource Hosts 254
!   

class MYcontext1-class
  limit-resource Routes 60
  limit-resource ASDM 5
  limit-resource VPN Other 500
  limit-resource VPN IKEv1 in-negotiation 40.0%
!


class blog
  limit-resource Conns 50000
!



and now apply to our contexts;

context MYcontext1
  description   EXTERNAL INTERNET FIREWALL INSTANCE
  member MYcontext1-class

context MYcontext2
  description   EXTERNAL INTERNET FIREWALL INSTANCE
  member MYcontext2-class

context Customer1
  member blog
context Customer2
  member blog
context Customer3
  member blog


18: When defining  context configurations files, it's best to stick with the common wording of <contextname>.cfg or <contextname>.config.


19: When defining  a context, it's helpful for  the name to reference the customer or purpose of the context.


e.g Possible naming convention for a MSSP environment

context  CUST.123748999

where  the digits are the customer contract, PON, or account number, etc.....


e.g Possible naming convention for a Enterprise Network

context DeptSCI
context DeptEng
context DeptSup

note: remember that you can always add more information in the  description under each context. Context names are limited to  32 characters 

The asa will also warn you if you use any wrong combinations of letters/numbers

e.g  ( typical warning when you exceed a name or add characters that are not allowed )

INFO: A context name must start and end with a letter or digit, and have as interior characters only letters, digits, or a hyphen.




 My last finally tip for today;

The cisco context mode allows for you to  execute commands on the other unit without logining into that other  unit

e.g [ your on the Context name "MYcontext1"  ( primary unit )  and need to see the configuration of Mycontext1 ( secondary unit ) ]

 MYcontext1/act/FW1# failover exec stand show run
: Saved
:
ASA Version 9.1(3) <context>
!
hostname FW1
enable password AxdBdfMunMbDEDPl encrypted
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-se

 ( output shorten )

or how about the  review files on the compactflash disk from the system context ;

act/FW1# failover exec standby  show disk0
--#--  --length--  -----date/time------  path
   24  32768       Apr 22 2013 14:24:18  coredumpinfo
   25  59          Aug 27 2013 06:32:08  coredumpinfo/coredump.cfg
   71  5003        Dec 17 2013 13:19:16  oldconfig_2013Dec17_1221.cfg
   72  32768       Aug 27 2013 06:40:52  tmp
   11  32768       Apr 22 2013 14:29:52  log
   22  32768       Jan 07 2014 20:37:18  crypto_archive
  102  5162176     Jan 07 2014 20:37:20  crypto_archive/crypto_eng1_arch_1.bin
   74  18097844    Aug 27 2013 06:26:06  asdm-713.bin

( output shorten )

The cli command "failover exec stand  < followed by the command> " will always work if the 2nd unit is enable and is up/reachable over the heartbeat  interface. You can revert the command if on the standby and need to review information on the active unit for example

e.g  the  cli command  "failover exec active show disk0 " issued   from the standby unit


stby/MAFW1# failover exec active show disk0
--#--  --length--  -----date/time------  path
   24  32768       Apr 22 2013 14:24:10  coredumpinfo
   25  59          Aug 27 2013 06:08:56  coredumpinfo/coredump.cfg
   77  4964        Dec 17 2013 13:05:54  oldconfig_2013Dec17_1207.cfg
   78  4492        Aug 27 2013 06:08:54  8_2_5_0_startup_cfg.sav
   11  32768       Apr 22 2013 14:29:58  log
   22  32768       Apr 22 2013 14:30:36  crypto_archive
 
( output shorten )

So don't be afraid of multi-contexts. A lot of good can comes from  virtual firewalling a hardware appliance.


Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   $  $  )=
          o
       /     \

5 comments:

  1. In preparing to implement, I found this very helpful - Thank you for spending the time to write this!

    ReplyDelete
  2. In preparing to implement, I found this very helpful - Thank you for spending the time to write this!

    ReplyDelete
  3. Hi Ken, why in some designs where ASA's are active/active and VPN services are required do the routers sit inside the network and the ASA's on the perimeter? Thanks

    ReplyDelete
  4. Angela, 1st thanks for reading the post. I'm not really following your question. In Active/Active the multiple contexts are active shared via the group.

    i.e

    act/SFASAFW1# show failover state

    State Last Failure Reason Date/Time
    This host - Primary
    Group 1 Active None
    Group 2 Standby Ready None
    Other host - Secondary
    Group 1 Standby Ready Comm Failure 10:30:25 PST Jun 17 2015
    Group 2 Active Comm Failure 10:30:25 PST Jun 17 2015

    ====Configuration State===
    Sync Done
    Sync Done - STANDBY
    ====Communication State===
    Mac set

    So FW primary has one context active and Secondary has the other. Where you place the routers is related to that context and the network(s) that your routing behind and the firewall policies that you allowed.

    Each context can have ipsec VPNs ( site2site only in multi-contexts as of 9.4.1 ).

    I hope that clarifies any concerns that you have.

    Ken@socpuppets

    ReplyDelete