cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
22309
Views
0
Helpful
14
Replies

ASA 5525-X management interface routing

darthnul
Level 1
Level 1

I am setting up a new active/standby pair of ASA 5525-X appliances.  They are currently running 9.4(2) code.  I have a couple of other ASA failover pairs in production but I never bothered setting up the management interface for those.

I thought I'd follow "best practices" and use the management interface this time but it seems the management interface uses the same routing table as the inside and outside firewalling/routing interfaces.  I kind of assumed this would be more like the management vrf setup used in switches but it's not even close.

Is it possible to restrict the control-plane traffic to using management0/0 and have "inside" hosts route to some of the same destinations via the "outside" interface?  For example, I want the ASA clock to synch to my internal NTP servers via the man0/0 but I need the servers to synch to those same NTP servers via the "outside" interface gi0/0.  What sort of routing gynastics are needed, and where might they be documented?

This installation is a little unusual as it i has no Internet connection.  It's just being used to segregate sensitive subnets from end-user and less sensitive (but "trusted") subnets.  OSPF is used throughout the network.

2 Accepted Solutions

Accepted Solutions

Yeah, I confirmed on an ASA with 9.5(1) that it has a separate table for management.  Another one I have with 9.3 does not.  For some reason I thought I had saw the command on older ones but probably not.

View solution in original post

Yes that was a long-awaited featured just introduced last fall in 9.5(1).

Before that, the management interface was useful primarily in two use cases (post initial setup):

a. Organizations with a true out of band management network

b. For the software modules (ips, cxsc and sfr) that used that physical interface as their communications path for configurations or communications back to their respective management platform (ips = IME or CSM, cxsc = Prime Security Manager, sfr = FireSIGHT / FirePOWER Management Center

View solution in original post

14 Replies 14

cmlozano8
Level 1
Level 1

From what I understand the management table is separate.  There used to be a command in the ASAs "show route management-only" but I have not seen it lately in some of the newer codes.

I also believe if the connection comes in on the management interface it will route back out that interface.  I am interested in this too because it seems like there was a change to this behavior at some point.

Thanks for the reply!

It looks like some 9.5 versions have a separate routing table for m0/0.  I'm beginning to wonder if there's any real benefit in bothering with the management interface at all with 9.4.  I'm not really interested in having the responses from my ASDM and SSH sessions getting routed back to me asymetrically.  It's been useful during my initial setup since I can verify my production AAA, logging, NTP functions, etc while keeping all the "inside" and "outside" interfaces in the lab, but I'm not sure I'd gain anything once it's all on the production network.

Yeah, I confirmed on an ASA with 9.5(1) that it has a separate table for management.  Another one I have with 9.3 does not.  For some reason I thought I had saw the command on older ones but probably not.

Yes that was a long-awaited featured just introduced last fall in 9.5(1).

Before that, the management interface was useful primarily in two use cases (post initial setup):

a. Organizations with a true out of band management network

b. For the software modules (ips, cxsc and sfr) that used that physical interface as their communications path for configurations or communications back to their respective management platform (ips = IME or CSM, cxsc = Prime Security Manager, sfr = FireSIGHT / FirePOWER Management Center

I've got the Firepower/sight bundle so there's a good chance it'll be enabled in the near future.  I've never done that with an ASA but I've been managing Sourcefire stuff going on ten years now.

Have you been running 9.5(1)?  Has it been stable?  This new ASA pair won't be in production for another week so I still have time to upgrade.

Actually we're running 9.5(2) here at the office.

I've deployed it at a couple of customer sites as well and it seems fine so far.

The current recommended versions that also supports the FirePOWER module would be the latest 9.4(2) interim build 6.

The module will use the physical management interface but the ASA software does not need to so the separate routing table for the base ASA isn't a critical path item there.

Think of it like two VMs on a hypervisor - the base ASA is one and the FirePOWER module is the other. The FirePOWER module is always mapped to the management interface. The ASA software is always mapped to all of the interfaces but you don't need to use them all.

So the Firepower module uses its own routing table instead of the ASA's?

That's correct. It's just a default gateway for the Linux kernel really - not a full fledged routing table.

The only thing the sfr module uses it for are management plane communications - to ASDM, FirePOWER Manager or to the cloud for things like URL categorization and sha-256 hash lookup for AMP file policies.

All data plane communications are via the internal backplane interface to the parent ASA. 

Does this apply ONLY to the Management0/0 interface or for any interface configured with 'management-only'?

Cheers

Andy

Andy,

I don't have one handy to confirm, but the configuration guide indicates that "management-only" will put the interface under the separate management routing table (if you have configured one).

I am looking at the statement "An interface configured with management-only is considered a management interface." found here:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/general/asa-96-general-config/route-overview.html#concept_40C0C8DE2C1247319250B9F7706C54A5

I saw a similar post regarding upgrades from a pair of older 5500 series to a pair of 5525X and think I've avoided most of the "gotchas" for deployment. I don't think we'll ever need to use the MGMT interfaces unless we install FireSIGHT / FirePOWER on a separate server. We considered doing a cluster, but we're going back to the primary / failover scenario for the implementation since that's how the current system is configured.

Please let me know if you see any issues with this:

ASA5525, 8192 MB RAM, CPU Lynnfield 2394 MHz, 1 CPU (4 cores)

ASA Version 9.4(2)11 (most stable per Cisco)

Device Manager Version 7.2(2)1

Licensed features for this platform:
Maximum Physical Interfaces       : Unlimited      perpetual
Maximum VLANs                     : 200            perpetual
Inside Hosts                      : Unlimited      perpetual
Failover                          : Active/Active  perpetual
Encryption-DES                    : Enabled        perpetual
Encryption-3DES-AES               : Enabled        perpetual
Security Contexts                 : 2              perpetual
GTP/GPRS                          : Disabled       perpetual
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 750            perpetual
Total VPN Peers                   : 750            perpetual
Shared License                    : Disabled       perpetual
AnyConnect for Mobile             : Disabled       perpetual
AnyConnect for Cisco VPN Phone    : Disabled       perpetual
Advanced Endpoint Assessment      : Disabled       perpetual
Total UC Proxy Sessions           : 2              perpetual
Botnet Traffic Filter             : Disabled       perpetual
IPS Module                        : Disabled       perpetual
Cluster                           : Enabled        perpetual
Cluster Members                   : 2              perpetual

This platform has an ASA5525 VPN Premium license.

We have a valid "Running Permanent Activation Key"

Peter,

That looks fine as long as you aren't running any SSL VPN client (e.g AnyConnect-based or clientless) remote access VPNs. 

After the ASAs are on-line, we plan to register AnyConnect. We plan to contact Cisco if we run into any issues since we already paid for the licensing.

Hi, all!

Yes, ASA starting with version 9.5(1) formally is able to separate table for management but it's not fully supported (example for 9.5(2)): 'copy' and '| redirect' go through different interfaces. Explanations are below.

We had something like a wiring diagram for our ASA5525-X:


               ^
               | Ext int
           +---+-------+
  Mgmt int |           |
    +------+ ASA5525-X |
    |      |           |
    |      +---+-------+
    |          | Int int
    |          |
    |          |
 +--V----------V----+
 |                  |
 |      Router      |
 |                  |
 +-^--^--^--^--^--^-+     +--------+
   |  |  |  |  |  |       |  TFTP  |
   |  |  |  |  |  +-------+ server |
  ...internal nets...     |        |
                          +--------+

And I found that copy and redirect uses different interfaces for access to tftp-server on internal network:

asa-mgmt# copy running-config tftp://tftp_server_ip/file - uses ASA management interface (I see mgmt source ip on tftp server)

asa-mgmt# sho running-config | redirect tftp://tftp_server_ip/file - uses ASA internal interface.

That is to say that the appeared in ASA 9.5(1) separate routing table for management-only interfaces not brough to full vrf like in ASR routers.

Review Cisco Networking for a $25 gift card