Cisco Zone-based Policy Firewall: Controlling Intrazone traffic

This post is intended to explain basic concepts pertaining to intrazone traffic within a Cisco Zone-based Policy Firewal (ZFW) environment. Before we start the discussion itself, it is relevant to emphasize that there have been major changes in the ZFW intrazone behavior since the inception of IOS 15.X.

On IOS 12.X releases, traffic between interfaces belonging to the same zone was allowed to cross the firewall without inspection.  More precisely, in this group of releases, it was not even possible to define intrazone ZFW policies.

Starting on IOS 15.0(1)M, intrazone traffic is blocked by default.
IOS 15.X releases allow the creation of intrazone policies (source and destination of traffic in the same zone). An example of such a policy is presented in the figure, for which we want to allow only ICMP and UDP traffic among interfaces that are member of the INSIDE zone.
It is important to observe that ZFW intrazone policies employ the same building blocks that have been used so far.

Controlling intrazone traffic with the Cisco Zone-based Policy Firewall

** Topics for Study:

  • Examine the show commands documented in this example.
  • Apply L3 restrictions to limit intrazone traffic. Your policy should only allow PING between the and subnets, while still permitting NTP from to the server.
  • What command can be used to display the ZFW policy structure ?

** Related Posts:



Filed under English, Firewalls, Security

6 responses to “Cisco Zone-based Policy Firewall: Controlling Intrazone traffic

  1. Sylvain Munaut

    Do you have a reference on pointing to this ?

    • Hi Sylvain,
      Zone-based Firewall information is found on the Securing the Data Plane section of Cisco IOS documentation.
      Please visit the following page: [] and
      check the topics:
      – Intrazone Support in the Zone-Based Firewall Application
      – Configuring Intrazone support in the Zone-Based Firewall Applications

      Hope this helps,

      • Sylvain Munaut

        Yes, I’ve seen the support for it and I can definitely configure it in my routers (running 15.2 and 15.1(4)M).

        _BUT_ when I don’t configure a zone-pair at all, traffic is allowed to flow / pass AFAICT (at least it’s what I observe). The same documents also says that intra zone traffic is ‘passed’ by default.

      • Sylvain,
        Please see my other post: “Zone Policy Firewall: Understanding the default deny behavior“.
        In summary:
        – two interfaces that are not part of any zone, can still communicate directly (irrespectively of the IOS image)
        – an interface assigned to a security zone cannot communicate with a non-zone interface.
        – Intrazone traffic is passed by default in pre-15 releases (for which you were not able to configure an intrazone zone-pair).
        Please notice that the document I mentioned belongs to 12.4T train (but talks about intrazone in 15.X releases…)

        Hope this helps,

  2. Sylvain Munaut

    Yes, I’m aware of behavior between non-zone interface and zone interface.

    But what I have here is a 1812 running 15.1(4)M3 where I have several interfaces in the same zone, no intra zone zone-pair defined and traffic flows between those interfaces.

    I can restrict the traffic if I define a zone pair with same source and destination, but by default, traffic flows, a bit like with the ‘self’ zone, where if you don’t have any zone-pair, traffic flows by default.

    I’ve just reconfirmed that in GNS3 right now. If I have

    “zone-pair security zp_test source zone_lan destination zone_lan”

    in the config, no traffic flows. But if I remove the zone pair (while still leaving both interface in zone_lan), then traffic flows. So it behaves exactly like with the self zone.

    • Hi Sylvain,
      My recommendation in such a situation is to open a TAC case and confirm the expected behavior.
      (It may be a bug…)
      I tested the following releases for Intrazone and they worked as described in the post:
      a) 15.1(4)M1, 15.2(2)T, 15.2(1)T1 for ISR G2 (2911);
      b) 15.0(1)M4, 15.1(2)T0a for ISR G1 (2811)
      Another suggestion before you install a different release is simply to reload the router before testing again.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s