Is SLA right for multiple inside interfaces?

[jim.mcnamara (James M)]

Hello! In the setup I am working on, I have three separate switches, each switch using its own subnet. The switch in each stack is the default gateway for all of the clients on that subnet, then the asa has a physical interface connected into each switch. The asa config looks like this:

interface GigabitEthernet0/1
nameif inside1
security-level 100
ip address 192.168.1.3 255.255.255.0
!
interface GigabitEthernet0/3
nameif inside2
security-level 100
ip address 192.168.2.3 255.255.255.0
!
interface GigabitEthernet0/5
nameif inside3
security-level 100
ip address 192.168.3.3 255.255.255.0
!

Each of the switches involved has a default route pointed to the asa’s address on that switch’s subnet, so the switch 192.168.1.1 on has the route:

route 0.0.0.0 0.0.0.0 192.168.1.3

while the switch 192.168.2.1 has the route:

route 0.0.0.0 0.0.0.0 192.168.2.3

and the final switch 192.168.3.1 has the route:

route 0.0.0.0 0.0.0.0 192.168.3.3

This works, but the switches are interconnected to each other and route between themselves using OSPF. The asa is not part of this traffic, so should a device on any of the subnets need to communicate with a device on any other of the LAN subnets, the switches would simply pass that traffic and the asa doesn’t see it.

An example of the problem I am trying to plan around would be if the asa’s interface inside1 goes down. While the interface with 192.168.1.3/24 would be down, the asa could still reach all of the 192.168.1.0/24 client devices through either the 192.168.2.1 switch, or the 192.168.3.1 switch. This sounded like a SLA setup, but as it turns out since the asa has an interface on 192.168.1.0/24, any time I try adding a route to 192.168.1.0 through the other inside interfaces, the asa spits the error, “ERROR: Cannot add route, connected route exists”. This makes sense as having an address on the subnet creates a route to it, but I don’t see a way to tell the asa, “should inside1 fail, you can still get to that subnet through inside2 or inside3”

If all the traffic had configured routes, then setting up SLAs seems it would be the way to go. Is there a way to accomplish this?

[lagapidis (Lazarus Agapidis)]

Hello James

That’s an interesting scenario. Indeed, the use of an SLA will not work simply because the ASA will not allow a static routing entry that is already directly connected. I was thinking that it may be possible to create a floating static route with a less attractive AD, but on the ASA it seems that’s not possible for directly connected networks. This may change from version to version, but I believe this is the case, at least from the context of this Cisco documentation.

So since SLAs and floating static routes are not possible, there are a couple of things I can suggest.

1. Make the ASA part of the OSPF routing. That way any changes to the topology will be dealt with using the routing protocol, rather than using static configurations. This is generally more robust and adaptable to network changes.
2. Reconsider the architecture. In general, firewalls are not ideal for routing between multiple internal segments. They are typically positioned at the network edge, primarily controlling traffic between inside and outside zones. A cleaner design would be to:
   • Let the Layer 3 switches alone handle inter-VLAN routing
   • Use transit networks between the switches and the ASA
   • Allow the ASA to route toward internal networks rather than be directly connected to each one

This second approach enables greater flexibility, including the use of dynamic routing or floating static routes where appropriate.

Let us know how you get along, so that we can continue the conversation and help you to get to the best solution for your scenario.

I hope this has been helpful!

Laz

[jim.mcnamara (James M)]

Thanks, Laz!

I believe I am following you. It doesn’t “feel” right to me to include the ASA in the OSPF as it doesn’t change how the switches route between each other. I’m not saying it would be wrong to do so, it simply feels like a square peg in a round hole type scenario.

So from your 2nd option, I’m thinking that I would change the current connection details so it would be something more like:

interface GigabitEthernet0/1
 nameif inside1
 security-level 100
 ip address 10.0.1.1 255.255.255.254
!
interface GigabitEthernet0/3
 nameif inside2
 security-level 100
 ip address 10.0.2.1 255.255.255.254
!
interface GigabitEthernet0/5
 nameif inside3
 security-level 100
 ip address 10.0.3.1 255.255.255.254
!

Then provide the other IP in that /31 to the switch where the firewall connects, then setup the route to the original networks by metric, like:

route inside1 192.168.1.0 255.255.255.0 10.0.1.0 10
route inside2 192.168.1.0 255.255.255.0 10.0.2.0 100
route inside3 192.168.1.0 255.255.255.0 10.0.3.0 101
route inside2 192.168.2.0 255.255.255.0 10.0.2.0 10
route inside3 192.168.2.0 255.255.255.0 10.0.3.0 100
route inside1 192.168.2.0 255.255.255.0 10.0.1.0 101
route inside3 192.168.3.0 255.255.255.0 10.0.3.0 10
route inside1 192.168.3.0 255.255.255.0 10.0.1.0 100
route inside2 192.168.3.0 255.255.255.0 10.0.2.0 101

Then the nat rules will probably get long, but it should work?

[lagapidis (Lazarus Agapidis)]

Hello James

@jim.mcnamara

I believe I am following you. It doesn’t “feel” right to me to include the ASA in the OSPF as it doesn’t change how the switches route between each other. I’m not saying it would be wrong to do so, it simply feels like a square peg in a round hole type scenario.

I understand your logic, and it is indeed a valid approach, so let’s go on to the topology and config you propose.

First of all, just a clarification.

@jim.mcnamara

Then provide the other IP in that /31 to the switch where the firewall connects, then setup the route to the original networks by metric, like:

The final number in your ASA route command is administrative distance (AD), not a routing metric in the OSPF/EIGRP sense. Your logic is correct but I just want to make sure it’s clear what you’re actually configuring.

These are called Floating Static Routes. The ASA installs the lowest-AD route into the routing table and keeps higher-AD routes as backups for the same prefix. This is structurally correct.

Static route failover on the ASA primarily reacts to local interface failure. Detecting remote path failure on an ASA is more limited than on IOS routers, so if end-to-end path-awareness is important, dynamic routing on the ASA is usually the better design.

Another issue you have to keep in mind is asymmetric routing. This is probably the most concerning design issue. The ASA is a stateful firewall, meaning it tracks connection state per interface. Consider this scenario:

A flow from 192.168.1.5 normally enters the ASA on inside1. If the internal switches reconverge and now reach the ASA through a different inside interface than the one originally used for the flow, the ASA may see the return traffic arrive on a different interface than expected, but its connection table recorded the flow as belonging to inside1.

Result: The ASA may drop the packet because the flow becomes asymmetric.

This is one of the main reasons many engineers prefer to run OSPF on the ASA in multi-path designs like this. However, if you choose to stay with static routes, IP SLA tracking greatly reduces (but does not completely eliminate) this risk by keeping the ASA’s routing aligned with actual path health.

Finally, concerning NAT, for Internet-bound traffic, PAT can usually be handled with a single general rule toward the outside interface. The more complex part is the identity NAT/NAT exemption for inside-to-inside flows.

For inside-to-inside traffic (between inside1, inside2, inside3 networks), you need NAT exemption (identity NAT) so the ASA does not try to translate internal-to-internal flows. These rules will grow with the number of interface pairs, but are manageable.

I hope this has been helpful!

Laz