Tunneling VPNs and Zone-Based Firewalls

Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.

Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services.

Until I have time to develop and publish comprehensive (and tested) configurations, use these rules to develop your zone-to-self policies:

  • You have to use access lists to classify traffic being sent or received by the router (you need access lists anyway, as the match protocol command cannot match ESP, GRE or OSPF).
  • You have to define two zone-pairs: self-to-zone and zone-to-self.
  • When using IPSec, the traffic to/from public IP infrastructure has to include esp, isakmp (UDP port 500) and non500-isakmp. ICMP and a few other things (for example, SSH to the router) are also highly advisable.
  • When using GRE tunnels without IPSec, the traffic to/from the router has to include gre.


  1. I have a 871w router on 15.0 code. I have a site-to-site VPN using VTI, a site-to-site using a tranditional crypto-map on the WAN interface, and have many zones, including the self zone.

    Cisco's documentation explains the self-zone can only inspect TCP, UDP, ICMP traffic. Given this limitation, you need to explicitly permit (not inspect) all other protocols such as OSPF, ESP, etc. Furthermore, you can not inspect some common traffic such as DHCP. I believe the reason for this is because the source or destination in DHCP traffic is majority of the time, and causes problem for inspection.

    I find it a shame that the IOS Zone Based Firewall can not inspect self-zone traffic much as the PIX and ASA products do. There has been many improvements recently... but the ZBF is still very poor compared to the PIX/ASA line.

    The zone-based-firewall is a great feature, but for the best approach, I would still recommend both IOS router... AND... a ASA firewall, as each have their own purpose. I can't wait for the zone-based firewall to be just as good as the ASA is.
  2. One last comment... I found most of my configuration assistance on NIL's IP Corner and IOS blog. 8-)
  3. Hi Ivan,

    Hiope you're doing well!

    I'm still facing the same issue "as stated on my email", when I apply " zone-member security Out" on my Tunnel200 interface, the peer "beuighbor" tunnel interface switch to down, but the Tunnel interface where in I apply the zone is still up and pingable.


    1. Should I apply the "IPSec.Out.and.In" ACL on the following interface

    interface GigabitEthernet0/0.2362 - this is the interface facing to PE Router

    1. IPSec / GRE setup is up and running (no issues), error only arise when I apply zone on the Tunnel Interface

    Below's the running config on Router

    interface Tunnel200
    description TO.DRC.SITE
    bandwidth 2000
    ip address a.b.12.21
    no ip redirects
    no ip unreachables
    no ip proxy-arp
    zone-member security Out
    ip tcp adjust-mss 1360
    load-interval 30
    delay 2000
    keepalive 10 3
    tunnel source a.b.125.210
    tunnel destination a.b.54.86
    interface GigabitEthernet0/0.2362
    description "TO.STC.MPLS.VPN"
    encapsulation dot1Q 2362
    ip address a.b.125.210
    crypto map cm

    ip access-list extended IPSec.Out.and.In ==I used this for both IPSec.Out & IPSec.In, still not working
    permit esp any any
    permit udp any any eq isakmp
    permit udp any any eq non500-isakmp
    permit icmp any any
    ip access-list extended crypt-in-list == this is the current setup
    permit icmp any any
    permit esp host a.b.54.86 host a.b.125.210
    permit udp host a.b.54.86 host a.b.125.210 eq isakmp
    permit udp host a.b.54.86 host a.b.125.210 eq non500-isakmp
    ip access-list extended crypt-out-list == == this is the current setup
    permit icmp any any
    permit esp host a.b.125.210 host a.b.54.86
    permit udp host a.b.125.210 host a.b.54.86 eq isakmp
    permit udp host a.b.125.210 host a.b.54.86 eq non500-isakmp
    class-map type inspect match-any IPSec.Out
    match access-group name crypt-out-list
    class-map type inspect match-any IPSec.In
    match access-group name crypt-in-list
    policy-map type inspect PM_IPSec.In
    class type inspect IPSec.In
    inspect - I changed this to pass, Tunnel Peer still down
    class class-default
    policy-map type inspect PM_IPSec.Out
    class type inspect IPSec.Out
    inspect - I changed this to pass, Tunnel Peer still down
    class class-default
    zone security Out
    zone securiry In
    zone-pair security IPSec.Out source self destination Out
    service-policy type inspect PM_IPSec.Out
    zone-pair security IPSec.In source Out destination self
    service-policy type inspect PM_IPSec.In

    Hope you can help me on this issue.

    Thank you,

  4. GRE keepalive problems. Read my post on GRE keepalives; very probably you have to allow GRE from Out to Self (possibly also from Self to Out).
  5. to me ZFW only improve security in terms of transit zones [non self]
    but as soon as you try to secure the self zone especially when terminating vpn connection lets say to cisco VPN clients which are mainly on a dynamic ip, u have no choice but to allow all udp traffic to your router by using access list in pass mode both ways :

    permit esp any any
    permit udp any any eq isakmp
    permit udp any any eq non500-isakmp
    permit icmp any any

    its like taking 2 steps forward and 3 steps back, as its does not matter how secure your rooms are if you leave your main door wide open
Add comment