Showing results for 
Search instead for 
Did you mean: 


IOS Firewall best practices

Hi guys,

What is the best practices when deploying the IOS Firewall feature on routers, especially on the 800 series routers?

I know that a router will never be a true firewall but those features are there to make them simulate...

Usually what I do is the following:

ip inspect name IOS_Firewall tcp

ip inspect name IOS_Firewall udp

And then I apply this on the Outside firewall:

interface FastEthernet4

ip inspect IOS_Firewall out



So far I've no problems but I was wondering if there is even a better way, which Im sure there is. Like for example, those 2 "inspect" statements will grab all tcp and udp packets, but what about for the other packets that have other protocols?

thank you in advanced


Hi Bro

The word "best" is very subjective but here's my 2 cents, when deploying IOS Firewall feature on a typical Cisco IOS Routers. This is provided you've the correct IOS FEATURE SET, as well.

Besides using the Cisco document as a guide in performing IOS security hardening on your IOS equipment regardless of the Router model as stated in there are other Cisco technologies that you could adopt (with caution, of course!!!) as well as listed below;

a) Flexible Packet Matching (FPM) or Modular Policy Framework (MPF)

b) Zone-Based Firewall (ZFW)


I hope I have answered your questions.

Warm regards,
Ramraj Sivagnanam Sivajanam
Karsten Iwen
VIP Mentor

If you have a quite simple Firewall-setup (like only two interfaces) it's fine to stay with CBAC (ip inspect). This system probably doesn't have a real future, as all effort on IOS-firewalling is going into ZBF. So don't expect any new fancy features there. But CBAC is still fine in situations where ZBF is just overkill.

For CBAC (as for any Firewall) you must make sure that all your protocols are inspected the right way.

If you only have TCP and UDP, your two staements above are fine. If you use any other protocol it could be needed to add an inspection. The inspections are divided into two classes:

1) Inspections that make your protocol work

2) Inspections that make a protocol more secure

The first class would be the inspection for FTP. Without the inspection FTP wont work in every situation because of the dynamic data-channels. In the same class are voip-inspections as SIP, H.323 and so on.

Then there are inspections that make your network more secure: I.E. esmtp-inspection. SMTP will work without the inspection, but with the inspection you can limit what a client (or attacker) can talk to your mailserver. Other inspections of this class are IMAP, POP3 and a couple more.

A best practice is the following:

- From the first class, only activate the inspections that are really needed for your traffic.

- From the second class, only activate the inspections where you need more control over an application and really understand what the inspection does. Just google for "pix mailguard" and read how many problems an inspection can make if it's used in the wrong way.

This is what I typically activate on a simple CBAC-setup:

ip inspect name FW tcp router-traffic

ip inspect name FW udp router-traffic

ip inspect name FW icmp router-traffic

ip inspect name FW dns

ip inspect name FW ftp

ip inspect name FW tftp

The parameter "router-traffic" inspects the traffic that is initiated by the router. So you can do http or dns, ntp etc. from your router to the internet whitout having to allow the return-traffic in your outside-ACL. For this parameter to work it's needed to activate the inspection outgoing on the outside interface the same way you have in your example.

Thank you for the simple approach to these types of questions. And  also good to know that Cisco has already ended the CBAC and is only  implementing the ZBF. I think I had read something about this before and  again very good you brought that up.

As you said, my current setup is pretty simple. 2  interfaces, LAN and WAN, and I just need to make sure that I can make  this Cisco 881W that I am currently working with look to be like a  firewall as close as possible. I've had too many customers where their  IT people had no clue how to deal with these things, specially for  applications that have an strange "return" behavior. But again I know  that there are more protocols and those questions will come up one day.

Question  though for the syntaxt you have in the "ip inspect" statements. The  word "router-traffic" at the end, is that really necessary? You said  that this is needed to allow return traffic to the router when the  router initiates the connection, but isnt this already allowed by the  statements themselves without the "router-traffic" word?

Unless Cisco changed it lately what I don't think, then the parameter is needed. Without the parameter, only traffic going through the router was inspected, but not the traffic that was originated by the router. So it is handled pretty much the same as ACLs where outgoing ACLs also don't catch the router-initiated traffic.

Content for Community-Ad