Zone-Based Firewall and self zone issues in a DMVPN environment

Unanswered Question

Hi,

I am getting crazy trying to understand and configure outside access to our customer router with Zone-Based Firewall.

Until now the customer was running IOS classic firewall and I decide to configure Zone-based firewall as it will give more flexibility.

The customer has a DMVPN network and the HUB router is a Cisco 2921 with following image: c2900-universalk9-mz.SPA.150-1.M1.bin and Security license.

I have configured the following Zone-pair and traffic flows betwen this zones is working find:

zone security INSIDE_LAN
zone security OUTSIDE_INTERNET
zone security DMVPN


zone-pair security INSIDE_OUT source INSIDE_LAN destination OUTSIDE_INTERNET

zone-pair security DMVPN_INSIDE_OUT source DMVPN destination OUTSIDE_INTERNET

zone-pair security DMVPN-TO-LAN source DMVPN destination INSIDE_LAN

But I have a real issue trying to reproduce the effect of the following Outside access-list (Inbound) on outisde interface used in the IOS classic Firewall with Zone-Based Firewall:

ip access-list extended OUTSIDEACL
permit icmp any any echo-reply
permit icmp any any echo
permit icmp any any traceroute
permit icmp any any time-exceeded
permit icmp any any unreachable
permit gre any any
permit udp any any eq non500-isakmp
permit udp any any eq isakmp
permit esp any any
deny   ip any any

I know I should use the self zone and I have also done that:

class-map type inspect match-all OUT-TO-SELF
match access-group name OUTSIDEACL  //I am using the ACL that I was using for IOS classic FW

!
class-map type inspect match-any SELF-TO-OUT
match protocol tcp
match protocol udp
match protocol icmp
!

policy-map type inspect OUT-TO-SELF
class type inspect OUT-TO-SELF
  pass
class class-default
  drop log

!
policy-map type inspect SELF-TO-OUT
class type inspect SELF-TO-OUT
  inspect
class class-default
  drop log

!

zone-pair security OUT-To-Self source OUTSIDE_INTERNET destination self
service-policy type inspect OUT-TO-SELF

!
zone-pair security Self-TO-OUT source self destination OUTSIDE_INTERNET
service-policy type inspect SELF-TO-OUT

Traffic initiated from the router (TCP,ICMP,UDP) is ok  and inspected but from OUT to self I have a real issue:

I loose my EIGRP neighbors cause the policy-map OUT-TO-SELF in denying ISAKMP from spokes (HUB router outside IP: 90.10.10.2):

FW-6-DROP_PKT: Dropping Other session 100.10.10.2:500 90.10.10.2:500 on zone-pair OUT-To-Self class class-default due to  DROP action found in policy-map with ip ident 0

No packets are matching the class-map OUT-TO-SELF:

policy exists on zp OUT-To-Self
Zone-pair: OUT-To-Self

  Service-policy inspect : OUT-TO-SELF

    Class-map: OUT-TO-SELF (match-all)
      Match: access-group name OUTSIDEACL
      Pass
       0 packets, 0 bytes

    Class-map: class-default (match-any)
      Match: any
      Drop
        414 packets, 55828 bytes

Futhermore no match in the access-list:

Extended IP access list OUTSIDEACL
    10 permit icmp any any echo-reply
    20 permit icmp any any echo
    30 permit icmp any any traceroute
    40 permit icmp any any time-exceeded
    50 permit icmp any any unreachable
    60 permit gre any any
    70 permit udp any any eq non500-isakmp
    80 permit udp any any eq isakmp
    90 permit esp any any
    100 permit udp any eq ntp any eq ntp
    110 deny ip any any

Do you have any idea why I am running in this issue? I guess I have misconfigured something but I thing the self-zone is not that easy to understand!

Regards,

Laurent

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
praprama Wed, 09/22/2010 - 02:50

Hi Laurent,

What's happening is interesting. What happens when you change the action for the class-map OUT-TO-SELF to inspect instead of pass?

Also, in the access-list you are matching, try matching just one access-list entry, that is, modify the access-list to look like below and see if it makes any difference:

ip access-list extended OUTSIDEACL

permit udp any any

Let me know how it goes!!

Thanks and Regards,

Prapanch

Hi Prapanch,

Thank you for your post.

What  I did is to reload the router and then there was match in the  OUTSIDEACL:

Extended IP access list OUTSIDEACL
     10 permit icmp any any echo-reply
     20 permit icmp any any echo
     30 permit icmp any any traceroute
     40 permit icmp any any time-exceeded
     50 permit icmp any any unreachable
     60 permit gre any any
     70 permit udp any any eq non500-isakmp (2 matches)
     80 permit udp any any eq isakmp (8 matches)
     90 permit esp any any (541 matches)
     110 deny ip any any

Here is the new config:

class-map  type inspect match-all OUT-TO-SELF
  match access-group name OUTSIDEACL

!
class-map type inspect match-any SELF-TO-OUT
  match access-group name Test

policy-map  type inspect OUT-TO-SELF
  class type inspect OUT-TO-SELF
  pass
  class class-default
   drop log
policy-map type inspect SELF-TO-OUT
  class type inspect SELF-TO-OUT
   pass
  class class-default
   drop log

!

ip access-list extended Test
  permit tcp any any
  permit udp any any
  permit icmp any any
  permit eigrp any any

zone-pair security OUT-To-Self source  OUTSIDE_INTERNET destination self
  service-policy type inspect OUT-TO-SELF
zone-pair security Self-TO-OUT source self destination OUTSIDE_INTERNET
  service-policy type inspect SELF-TO-OUT

but  one of the eigrp neighbor is comming up and down and the FW is droping  connection form the router to OUTSIDE:

%FW-6-DROP_PKT: Dropping Unknown-l4 session  90.10.10.2:0 100.10.10.2:0 on zone-pair Self-TO-OUT class SELF-TO-OUT  due to  Invalid Segment with ip ident 0

Sep 22 10:43:38.183  UTC: %FW-6-LOG_SUMMARY: 11 packets were dropped from 90.10.10.2:57880  => 100.10.10.2:53 (target:class)-(Self-TO-OUT:SELF-TO-OUT)   *****Don't what DNS port  53 is doing there***

*Sep 22 10:39:27.507 UTC:  %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.2.0.2 (Tunnel1) is down:  retry limit exceeded
*Sep 22 10:39:31.567 UTC: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor  10.2.0.2 (Tunnel1) is up: new adjacency

Actually I  find out that this log : %FW-6-DROP_PKT: Dropping Unknown-l4 session  90.10.10.2:0  100.10.10.2:0 on zone-pair Self-TO-OUT class SELF-TO-OUT due to  Invalid  Segment with ip ident 0 means ESP protocol 50. So I had  permit esp any any to the Test access-list and that was find:

Extended  IP access list Test
     10 permit tcp any any
     20 permit udp any any (93 matches)
     30 permit icmp any any
     40 permit eigrp any any
     50 permit esp any any (76 matches)

So  I have concluded the following and correct me please if I am wrong:

1-  In my first problem whre I needed to reload the router to get some  match in the OUTSIDEACL is because the IPsec SA exchange was already  made when I configured the ZBF policies and ZBF will only affect new  connection, not existing connections. Maybe I could have done a: clear  crypto sa.

2- As was the  case with classical stateful  inspection, router-generated           traffic is limited to TCP, UDP, ICMP, and complex-protocol inspection  for           H.323 so you have to do a pass for esp in order to build the tunnel  up.

I attach some rules regarding self-zone:

Please Rate if it helps!

Regards,

Laurent

praprama Wed, 09/22/2010 - 07:07

Hi Laurent,

1) Clearing the ipsec sa could have helped and is a good suggestion but ideally it should not really be necessary. I am saying this because i have seen all of this working without the need to clear the tunnel, previously.

2) That's an interesting point you put forward and have not really had a chance to try it out. I have seen inspection work for protocols such as ESP as well and according to me, the inspect action also should work for ESP. Though inspection does do deep packet inspection for protocols, it also is used to allow return traffic by creating a session entry for sessions (which can be verified using the command show policy-map type inspect zone-pair NAME sessions).But again, ZBFW is pretty unpredictable and at times things we think should work do not end up working because of some other conflicts in the config, etc.

Thanks and Regards,

Prapanch

Atri Basu Mon, 12/27/2010 - 02:53

Hi Laurent,

It appears as though you might be running into bug #CSCta00183. Do you see drops like this in the ip inspect logs :

*Jun  5 16:09:38.583: %FW-6-DROP_PKT: Dropping Unknown-l4 session 20.20.20.3:0 20.20.20.1:0 on zone-pair out-self class class-default due to  DROP action found in policy-map with ip ident 0

Regards,
Atri

michael.perry Wed, 01/05/2011 - 12:34

We just got a new router with Zone Firewall functionality. I was considering using the feature or not and asking these same questions. If gre and esp are not in the list of protocols that can be matched, I assume the only option is to use an ACL. If the protocols must be specified in an ACL, why not just apply the ACL to the interface? I don't see the benefit of using Zone Firewall in my case, which is similar to the posted case. Please enlighten me if possible.

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a0080a63b94.shtml#topic1w

I found this Cisco site that offers a solution for problem "Unable to pass VPN Traffic". The commands appear to inspect all traffic specified in an ACL. Does anyone know if invoking the Zone Firewall with the "class-map type inspect" commands cause anything more indepth to happen than an ACL is queried? In the case from the link above the ACL is permit IP source to destination address only, which is not more indepth than the ACL already does? If not I don't see a need to use Zone Firewall in the case of DMVPN unless you have ACL's on your private and public and possibly DMZ segments and you need return holes established. Anyone have any insight on this? I'm new to Zone based Firewall.

Mike

Actions

This Discussion