The self zone in zone-based firewall configuration

One of my readers made an interesting observation when faced with configuring zone-based firewall on Cisco IOS: „My main issue is a confusion between when to use self and when to use in/outside.“

The rules are simple:
  • Whenever you filter traffic transiting the router, you control it with a zone-pair specifying an inside and an ouside zone.
  • The self zone controls traffic sent to the router itself or originated by the router.
  • Unless you specify a zone-pair combining self zone with another zone, all traffic from that zone sent to the router itself is allowed (the router is not protected)
  • To control traffic that the router can send into a zone use a zone-pair from self to another zone. Use inspect in the service-policy to allow the return traffic.
  • To filter the traffic that the router can accept, use a zone-pair from another zone to self. Only the packets accepted by this zone-pair's service-policy will be accepted by the router.
More information about the self zone (as well as other aspects of zone-based firewall configuration) can be found in my digital book Deploying Zone-Based Firewalls published by Cisco Press.


  1. A request for the an article here, or the next edition of your book is how to configure PPTP through NAT for remote access to a LAN server.

    It seems straightforward enough: enable PPTP and gre (via an access list ...) from out to in, but if you limit in to out traffic, you need to configure PPTP and gre in that direction too.

    But here's the kicker. I have a rule that denies in->out traffic that claims to be from my next hop out (as well certain broadcasts). This is what SDM deposits, just as it did for classic ACLs. Unfortunately, when combined with NAT, the in-out gre tunnel appears to be coming from my WAN ip address (ie, self) and so gets dropped. The solution seems to be to allow gre to precede the spoofing filter.
  2. If somebody tries to activate NAT/PAT (just run "ip nat inside / outside commands, even

    with an empty or dummy access-list so that NAT/PAT is really unused) with the zone-based

    policy firewall (ZPF) feature a surprise will happen when the router/firewall starts

    receiving GRE packets from both sides (triggered by an on-going PPTP session to an inside

    VPN server). In my scenario the class map access lists I'm using show "apparently" strange

    results. If somebody want I can share detailed configuration/information and an

    "unfriendly" but functional workaround. I'm running IOS Version 12.3(11r)T2, RELEASE SOFTWARE (fc1).
    I suppose this is an IOS bug. I suggest that Cisco starts supporting automatically GRE

    tunnels created by PPTP sessions like PIX products already supports. Suggested workarounds make the configuration complex and error prone. I appreciate more comments on this subject.
    By the way ... I find out that the ESMTP L7 DPI inspection is also very restrictive/poor. For instance, it is not possible to use it with Microsoft Echange servers since this server uses several unsupported service extensions.
  3. I too have fallen foul of this PPTP/GRE problem with zone-based firewall.

    I am trying to connect to a Win VPN/RAS server out on the internet but am getting an XP client "Error 806: A connection between your computer and the VPN server has been established, but the VPN connection cannot be completed.... Verify that protocol 47 (GRE) is allowed..."

    Unfortunately neither SDM not the CLI allows me to specify "gre" as a class-map match protocol.

    I've even tried opening up everything to that destination but with no success:
    class-map type inspect match-any ABC-VPN
    match protocol tcp
    match protocol udp
    match protocol icmp

    I'm not clear how I'd use an ACL at the same time to specify it.

    I have a static NAT for the client (i.e. no pool/overloaded ports).

    IOS: 12.4(11)T2 and now 12.4(15)T1 running on a C1841.

    Any ideas or pointers?
  4. Below is the solution I’m using as a “reasonable” workaround to the problem. Basically the router is instructed to inspect incoming PPTP traffic and to open holes (“pass”) on both directions to the GRE traffic.
    OUT (Internet) -> IN (VPN concentrator’s network)

    ip access-list extended outin-vpn-acl
    remark VPN Concentrator (PPTP sessions)
    100 permit ip any host IP_VPN_SERVER ! VPN Concentrator

    ip access-list extended outin-vpn-gre-tunnels-acl
    remark Workaround: GRE tunnel traffic target to the VPN Concentrator
    100 permit gre any host IP_VPN_SERVER ! VPN Concentrator

    class-map type inspect match-all outin-vpn-cm
    description Match PPTP sessions targetted to the internal VPN concentrator.
    match access-group name outin-vpn-acl
    match protocol pptp

    class-map type inspect match-all outin-vpn-gre-tunnels-cm
    description Workaround. Match GRE traffic targeted to the internal VPN concentrator.
    match access-group name outin-vpn-gre-tunnels-acl

    policy-map type inspect out-in-pm

    class type inspect outin-vpn-gre-tunnels-cm

    class type inspect outin-vpn-cm

    IN (VPN concentrator’s network) -> OUT (Internet)

    !######## Return traffic from VPN server
    !Workaround. The source address should be limited to the VPN servers public address.
    !However the current IOS version has problems dealing with GRE packets.
    !Review on a next IOS version > 12.4(11)T2
    ip access-list extended inout-vpn-gre-tunnels-acl
    100 permit gre any any ! Nortel VPN Concentrator
    110 permit gre any any ! Nortel VPN Concentrator

    !######## VPN (GRE) class map (to be used by the "in-out-pm" policy map)
    !Workaround. Check notes for the "inout-vpn-gre-tunnels-acl" ACL.
    class-map type inspect match-all inout-vpn-gre-tunnels-cm
    description Workaround. Match GRE traffic sourced the VPN concentrator.
    match access-group name inout-vpn-gre-tunnels-acl

    policy-map type inspect in-out-pm
    !Workaround. Check the notes written at the "inout-vpn-gre-tunnels-acl" ACL.
    class type inspect inout-vpn-gre-tunnels-cm
  5. "To control traffic that the router can send into a zone use a zone-pair from self to another zone. Use inspect in the service-policy to allow the return traffic."

    I believe that traffic to/from self zone cannot be inspected, just passed, at least with ios 12.4(24)T.
    1. That was a limitation in early ZBFW implementation. I think it should work now (I vaguely remember discussing this subject, but it was year or two ago).
  6. Hello Ivan, I added your ZBFW shortcut to my Safari books online bookshelf because it is a good reference. Were you planning to update it or publish it?
    1. If "publish" means in paper form, the answer is "no", but you can buy it on Kindle or as PDF.

      The update decision is in hands of Cisco Press and I haven't heard from them in years. Also the sales are pretty low, so I don't expect them to approach me with an update idea any time soon.
Add comment