Routing issue on Management network, ASA5540/SSM-20 AIP

rsmith · ‎03-30-2009

I have the following setup on our network:

ASA5540 SSM-20 AIP module, 10.255.x.x

PIX Firewall <===>ASA5540 Management, 10.255.x.x

/\ /\

| |

\/ \/

Router<===> ASA5540 Firewall <===> Internet (Cisco updates)

The only access to/from the 10.255.x.x network is from specific Network staff computers, and to the Cisco IPS update site.

Staff computers are translated into local 10.255.x.x IP;s, the Cisco update IP is allowed through (static to itself)

The issue is that since there is already a Route to the 10.255.x.x network, (Management interface directly connected for the ASA5540) there is no "return path" for the updates. (packets are dropping in the ASA5540 on return from Cisco.)

I do NOT want direct access from the ASA Outside or Inside interfaces to the Management interface, rather it should flow through the Inside network, through the Router, through the PIX, to the ASA SSM module.

How can I get the auto-update to work in this scenario?

Thanks in advance

Russ

a.alekseev · ‎03-31-2009

just do not use management interface

rsmith · ‎03-31-2009

uh... that's an answer? and you are a CCIE? Part of our Security posture is having an "out-of-band" management network. Only the Network staff and monitoring systems have access to this network. Since the SSM-20 AIP management interface is on this network, its update traffic needs to flow as described. I "could" change the ASA Management interface, but that defeats our Security rules. A "real" answer would be helpful, I cannot believe you actually posted that reply...

a.alekseev · ‎03-31-2009

By ASA's design the network 10.255.x.x MUST be reachable only via one interface.

In your case the net 10.255.x.x on one hand is reachable through inside, on the other hand - through management.

rsmith · ‎03-02-2010

I have taken the liberty of calling this a "Bug", and am in the process of a TAC case and Enhancement Request through our Account Manager.

My position is basically, if the Management0/0 interface is set to "management-only" (the default), it should NOT be participating in any of the "traffic" interface algorithms. (Routing, connectivity, etc.).

It should be fully Out-of-Band.

The "traffic" interfaces should not "see" the Management0/0 network.

There should be the capability of adding a Default Route/Gateway to the Management0/0 interface.

Kureli Sankar · ‎03-02-2010

Strange scenario..causing asymmetry.You are probably seeing deny tcp no connection messages 106015..

Would it help to split the mgmt network add routes pointing to the inside interface?

route inside 10.255.0.0 255.255.255.128 x.x.x.x

route inside 10.255.0.128 255.255.255.128 x.x.x.x

-KS

rsmith · ‎03-02-2010

Somewhat ironic since changing the Routing won't allow a return path. My "work-around" has been to do static NAT for the Management devices on the PIX515E (to the PIX device inside network IP range), and static/dynamic NAT for "internal network ITmanagement devices" into the Management network. What a mess!. Uses WAY too many IP's in both networks!

The TAC case and my Account Manager are working on a "Feature Enhancement", but if you search the posts, this issue has been around since ~ 2007 time-frame! I just wonder why Cisco has not addressed this issue before? LOTS of unhappy campers, and the mantra seems to be "don't use management interface" (so why is it available, then?)

Simple fix: Management configuration is not "shared" with the production interface configuration in "management-only" mode. Fixes "spoofed" issues, and allows a "Default Route" on the Management interface to the Routed uplink...

jcosgrove · ‎03-02-2010

I think your solution will involve running the ASA in multiple security context mode. Each ASA comes licensed for 2 security contexts.

When in this mode you have ADMIN,Context1 and Context2(if you only have 1 firewall then you only need Context1. The ADMIN context does not count against your license count.

Thru the ADMIN context you can assign the Management Interface to the ADMIN context and set up your routing for that area then connects your IPS management interface into this area and then route thru your Management network out to cisco to get your updates. Or setup your updates on an internal server and let the IPS get them from that point if security is an issue for this area.

Set up our normal firewall in Context1 and set up all your routing as appropriate for this area.

I hope this solves your issue. I have just started working with the multiple context mode and found this to solve the issue you brought up. I too found it difficult to imagine the use of the Management interface untill I considered the Multiple context or L2 modes of the firewall. With both of these configs I can easily imagine the use of the Management interface.

Good Luck.

JC

Kureli Sankar · ‎03-02-2010

Here are the other two options.

1. We usually suggest to put these in the inside just like any other PC or server as it has to go out to the internet to get updates. This would move this out of the mgmt interface and all will be good.

2. The other option is to allow asymmetry by doing tcp state bypass (new in 8.2) just for this traffic such that the traffic goes from inside to outside but the response goes from outside to dmz.

You can read about tcp state bypass here:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s1.html#wp1428242

I would go with option 1 and plug just the IPS module on the inside vlan.

-KS