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.
ASA(config)#router ospf 1
ASA(config-router)#network 192.168.1.0 255.255.255.0
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:
ASA(config)#router ospf 1
ASA(config-router)#no network 192.168.1.0 255.255.255.0
ASA(config-router)#redistribute connected subnets
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.
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.
9 Replies to “Cisco ASA – OSPF passive interface is…inactive”
Hi, Im not sure if I understand what you want to do either turn off the ospfs hello packets or to restrict the route propagation on the inside.
If you want to turn of the hello packets, theres no hope 🙁
If you want to restrict/filter the routes that you can propagate on the network for security reasons, you can use at interface level the ospf database-filter all out command. It will prevent the leak of information about your networks. I hope this helps.
Hi Conesh, the reason I state in the article is to have an interface as an internal OSPF route without OSPF running on that interface. Please see earlier comment from Cisco stating this has been raised as a bug but with no ETA.
if you don’t want your ASA to search for ospf neighbor on particular interface, issue interface-level command “ospf network point-to-point nonbroadcast”.
Although the command seems strange, what it does is it actually disables sending ospf hello messages to 22.214.171.124 link local group address.
Could you tell us which IOS version you have encountered this ? Or it is on all of them ?
OK, I’ll try a second reply as my initial one was to somebody else’s question relating to a different post! Yes, this lack of functionality appears to be across all 8.x and later releases. Hopefully, it will be resolved in the near future but the fact its been missing for so long doesn’t give me much hope.
I did not know that the “redistribute connected” only advertised classful networks. Interesting tidbit.
Yes, and good to have both options at our disposal.
Thanks Stefan for engaging. Strange oversight but glad to see it is coming.
There’s no valid reason why we left this out – more a bug – we have a enhancement request running to tidy this up – no ETA
If you have access to the bug tracker:
CSCsl72727 Bug Details
Add passive interface support to OSPF routing
This is an enhancement request to add passive interface functionality to the OSPF routing process on the ASA firewall platform. Currently it is not supported in OSPF but supported in EIGRP.