zone based firewall

Unanswered Question
May 25th, 2010

in the old style stateful firewall, we have:

ip inspect myfw icmp

ip inspect myfw ftp

ip inspect myfw tftp


access-list ingress permit ssh from my ip

access-list ingress permit icmp from my ip

access-list ingress permit vpn from anywhere


interface outside

  ip inspect myfw out

  ip access-group ingress in


if i need to make any changes to the stateful firewall (acl ingress or myfw), i simply do the following:

conf t

interface outside

no ip inspect myfw out

no ip access-group ingress in

make my changes and add the 2 lines above back in under the interface outside.  clients connected would not lose their connections to the internet, and i would not lose my PUTTY session to the router.


with the new style zone based firewall, you can use the self zone to control router access.  you would have something like this:

zone-pair security pub-self source public destination self
service-policy type inspect to-self-pmap
zone-pair security self-pub source self destination public
service-policy type inspect from-self-pmap

zone-pair security pub-priv source public destination private
service-policy type inspect pub-priv-policy
interface outside

zone-member security public


to change anything on the firewall, i would do the following:

  take the affected interface out of the affected zone, make my changes in the policy/class maps, reapply the interfaces to the zones.  this is where i would lose the putty connection to the router.  for example, if i want to change the self zone firewall/acl, i would have to take the interfaces out of the zones, make my changes and reapply the interfaces back into the zones.  however i am not able to complete the tasks of adding interfaces back into the zones without losing SSH connection to the router - sometimes the connection lost is permanent.  what am i doing wrong?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Panos Kampanakis Tue, 05/25/2010 - 14:35

When an interface is a part of a zone then it cannot talk to non-zoned interfaces.

So while configuring, if you put the interface you are behind behind a zone, it will not be able to go to any other interfaces unless it is in a zone and the corresponding zone pair allows it.

Also, if you have zone pairs that have the self zone in them, then the moment you put an interface behind a zone that is in a zone pair with the self zone your management traffic will be subject to the policies of that pair. So if you missed something in the policy you could lock yourself out

My suggestion would be to configure zone pairs for self to your interface zone and your interface zone and self. Then match on management traffic (telnet or ssh) and "pass" that traffic with ZBF for both zone-pars. Then put your interface behind your zone. Zone to self and self to zone is passed so the router should be still manageable with ssh or telnet.

Then you can keep on setting up ZBF.

Keep the "reload in xxx" minutes command without saving the config which you could use before putting the zone membership is so that the router will reload if you lock yourself out. "reload cancel" will cancel the reload.

I hope it helps.


m.kafka Tue, 05/25/2010 - 15:13

First: the "IOS Classic Firewall" never inspected traffic to or from the router, that is clearly documented.

In a zone based firewall the policy actions are handled in a special way if the self zone is affected:

Any zone can communicate with the self zone and vice verse if no zone pair is defined regardless whether the source or destination is member of any zone.

- If the a zone pair is defined, which includes the self zone and any other zone and no policy is attached you can still communicate

- policy actions are only enforced if a zone pair exists which includes the self zone and any other zone and a policy is attached

which means: as soon as you attach a policy to the zone pair e.g. pub-self the inspection will kick in, invalidating a previously established ssh sesion from the zone public.

To keep your ssh session you could try to define a class map which selects ssh and within the policy map you use the action pass instead of inspect for this class to permit packets unconditionally (without inspection). You would also need another zone pair self-pub which unconditionally passes the ssh return traffic.

If you loose the connection permanently (you cannot reconnect) then you should review your class-maps and policy-maps.

Alternatively to the self zone you can use the control-plane with port filters and or policy maps but this is a totally diferent story

I recommend the feature guide for control-plane especially:

Control-plane host subinterface—Subinterface that receives all control-plane IP traffic that is directly destined for one of the router interfaces. Examples of control-plane host IP traffic include tunnel termination traffic, management traffic, or routing protocols such as SSH, SNMP, BGP, OSPF, and EIGRP. All host traffic terminates on and is processed by the router. Most control-plane protection features and policies operate strictly on the control-plane host subinterface. Since most critical router control-plane services, such as routing protocols and management traffic, are received on the control-plane host subinterface, it is critical to protect this traffic through policing and protection policies. CoPP, port-filtering, and per-protocol queue thresholding protection features can be applied on the control-plane host subinterface.

update: here is a nice presentation on zone based firewalls (zone self is on slide 15):

Message was edited by: m.kafka

tachyon05 Wed, 05/26/2010 - 11:28

thanks.  am i correct with the following then?

if i simply want to allow client to get on to the web, i just need 2 zones (priv and pub), and only 1 zone pair (priv-pub)?

if i would also need vpn and control access to the router, i would need 3 zones (priv, pub, and self), and 4 zone pairs (priv-self, self-pub, pub-self, and self-priv)?  further more, access control to the router will fall under the pub-self and self-pub zone pairs, vpn class map/policy will fall under all 4 zone pairs?

Panos Kampanakis Wed, 05/26/2010 - 11:39


Depending on what you want to allow you might not need a couple of pair in the latter case.

For example if you don't define a pair that has self the vpn will come up, but will not have limited what traffic will go to the self zone.


tachyon05 Wed, 05/26/2010 - 13:31

thanks.  it appears that the control plane security features are extensive.  it appears that i can use ZFW for the priv and pub zones, while using control plane to control access to the router.  can anyone provide a link to or a quick example?  for example, only allow ssh, icmp, http, https from host while allowing vpn from anywhere.


This Discussion