Cisco ASA – OSPF passive interface is…inactive

Introduction

I recently came across a quirk in the ASA’s implementation of OSPF that is widely known but I thought I’d share it here anyway. With the firewall being placed at the security boundary that quite often connects to the Internet on the outside interface, you would most often have a default route redistributed in to OSPF, although of course you could also be talking OSPF to your service provider depending on your situation.

However, in my home lab, the lab itself terminates on an ASA, which has it’s outside interface on my home LAN. I connect in to my lab from that LAN through the ASA and so wish to advertise that network in to the lab for reachability.

All well and good. Except that I have no OSPF speakers on my home LAN and the ASA, by virtue of line 2, is now desperately trying to chat something up on 192.168.1.0/24. In my situation, this is mostly harmless. In another, it poses a security risk as anybody could in theory fire up an OSPF speaker, learn about the internal routes and inject it’s own. Obviously, there are ways to protect this from happening e.g. MD5 authentication but quickly firing up Wireshark shows me the traffic is there and I hate seeing traffic on the wire that doesn’t have to be (Dropbox LAN Sync, I’m looking right at you!).

OSPF passive interface

So it makes perfect sense to use the OSPF passive interface functionality in this scenario. This allows me to turn OSPF chatter off on an interface. In conjunction with the network statement on line 2 above, I can advertise the network in to OSPF, but OSPF will not try to talk on the interface. Job done.

Except that for some reason, the ASA does not support this. The command exists under the RIP and EIGRP configuration modes but not OSPF. One possible way to resolve this would be:

Let’s remove the network statement. This removes the network from being advertised and also stops OSPF talking on that interface. Line 3 redistributes connected subnets (duh, obviously!) in to the OSPF process.

As a side note, line 3 advertises subnets as they are configured on the interface e.g. 192.168.1.128/25 would be advertised as such. If you miss the ‘subnets’ keyword off, it will only advertise classful networks, in our previous example, 192.168.1.128/25 would not be redistributed. Also, if you have the subnets keyword already added, negate the full line before adding it back in without the subnets keyword. It warns that only classful networks will be redistributed, but if you check the config, the subnets keyword remains and, in our example, 192.168.1.128/25 would be redistributed. More quirkiness.

Summary

Perhaps somebody reading this has insight as to why this functionality has been missed off the ASA platform. The workaround discussed above isn’t perfect either. Anything redistributed will show as an external route in your routing table and quite often that isn’t what you want.

Till the next time.