2

Hoping somebody can help me understand what I'm doing wrong here. Here is the diagram:

[![enter image description here][1]][1]

We have an ASA sitting at the edge. The FirePower module is connected via the management interface (with "no ip address" configured on ASA, but IP configured on FirePower). The ASA is managed through interface 1/2.

There is an exit subnet configured that should be used for routing all traffic to/from the outside.

The environment has a separate subnet for management (physical devices mostly, hyper-v, storage, etc) which is the 10.10.5.0/24 network and another subnet for end-user-accessed servers, pretty much all VMs. The ASA has to contact some of these servers for various network services like DNS, RADIUS, and others. So if I want the ASA to authenticate a VPN user through RADIUS, I would like it to send that traffic via 10.10.5.1, not 172.16.98.1. I can't get this to work. I believe the routing is breaking. I've been reading about management-only routes, but I can't seem to wrap my head around what I'm doing wrong here. The TAC engineer is very intelligent, but uninterested in going beyond break/fix. Is this is architecture design flaw?

Much appreciated.

  • You need to edit the question to include the sanitized (obfuscate public addresses and passwords) network device configurations. – Ron Maupin Mar 2 '18 at 19:53
  • Done, sorry about that! – Arty Mar 2 '18 at 20:15
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 25 '18 at 8:03
1

I know this is not the answer that you're hoping to hear, but the answer is to manage your ASA in-band, not out-of-band. The ASA does not have VRF capabilities, meaning that the Man1/1 port (or whatever interface you designate, like Gig1/2) does not have a separate routing table, but rather functions like a regular interface and uses the regular routing table. This can cause several issues in the way the device processes certain traffic flows.

Your best path forward is to shutdown your Gi1/2 interface, and remove the MANAGEMENT_SUBNET nameif. Then, add a static route for the 10.10.5.0/24 pointing to 172.16.98.1 like everything else.

All your problems will then go away except your nagging desire to manage the firewall on the management network, "like everything else". The thing is, your firewall isn't like everything else. Management networks are designed for non-network devices (meaning servers, storage, whatever else) and probably layer 2 switches. Layer 3 devices like routers and firewalls use their IP addresses to make behavioral decisions, and are much more effectively managed with a loopback address, or an in-band IP address.

  • 1
    I have to strongly disagree with the latest part. Out of band management for network devices is a thing and it has some real advantages. – JFL May 21 '18 at 17:44
  • Emphasis on the word some. – user3629081 May 21 '18 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.