09-22-2010 02:23 AM - edited 03-11-2019 11:43 AM
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
09-22-2010 02:50 AM
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
09-22-2010 04:34 AM
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
09-22-2010 07:07 AM
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
12-27-2010 02:53 AM
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
08-24-2018 01:53 PM
u r rock man
may be it's quite late but in the lab with 12.4(22)T problem was resolved with standard ACL (permit host) in each direction
br andy
01-05-2011 12:34 PM
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.
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: