Zone-Based Firewall policy - not blocking icmp

[ddolbel]

Hello All

i'm hoping you can assist me, i'm trying to convert from the old ip inspect firewall rules to zone based policy's

I have worked out most of the setting however I can't seem to get outside icmp blocking to occur

I want clients inside the network to be able to ping, just not the big bad internet pinging my wan interface.

I have tried acl's on the in bound interface but then clients inside the network can't ping

I tried adding class to match icmp and block it however that didn't work

here is my zone-based policy config thus far

class-map type inspect match-any INSIDE-TO-OUTSIDE-CLASS
match access-group name INSIDE-TO-OUTSIDE
class-map type inspect match-all OUTSIDE-TO-INSIDE-CLASS
match access-group name OUTSIDE-TO-INSIDE

class-map type inspect match-all OUTSIDE-ICMP-POLICY
match protocol icmp

policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
class type inspect INSIDE-TO-OUTSIDE-CLASS
inspect
class class-default
drop log
policy-map type inspect OUTSIDE-TO-INSIDE-POLICY
class type inspect OUTSIDE-TO-INSIDE-CLASS
inspect
class type inspect OUTSIDE-ICMP-POLICY
drop
class class-default
drop log

!

zone security INSIDE
zone security OUTSIDE
zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE
service-policy type inspect INSIDE-TO-OUTSIDE-POLICY
zone-pair security OUT-TO-IN source OUTSIDE destination INSIDE
service-policy type inspect OUTSIDE-TO-INSIDE-POLICY

ip access-list extended INSIDE-TO-OUTSIDE
10 permit ip any any

ip access-list extended OUTSIDE-TO-INSIDE
10 remark Allow Inbound Connections
10 remark VPN Connection
10 permit gre any any
20 permit udp any any eq non500-isakmp
30 permit udp any any eq isakmp
40 permit esp any any
50 permit ahp any any
60 permit tcp any any eq 10000
70 remark Internode SIP UDP 5060
70 permit udp host <removed> any eq 5060
90 remark DNS Access TCP (53)
90 permit tcp any any eq domain
100 remark DNS Access TCP (53)
100 permit udp any any eq domain
170 remark HTTPS (443) Access TCP
170 permit tcp any any eq 443
180 remark HTTPS (443) Access UDP
180 permit udp any any eq 443
190 remark NTP (123)
190 permit udp any any eq ntp
220 remark ESET ESMC Management Agent (2222) TCP
220 permit tcp any any eq 2222
260 remark Deny ICMP
260 deny icmp any any
270 deny ip 10.0.0.0 0.0.0.255 any
280 deny ip 172.16.0.0 0.15.255.255 any
290 deny ip 192.168.0.0 0.0.255.255 any
300 deny ip 127.0.0.0 0.255.255.255 any
310 deny ip host 255.255.255.255 any
320 deny ip host 0.0.0.0 any
330 deny ip any any

interface GigabitEthernet0/0/2
description GLECSW01_Gi1/0/1
ip address 10.0.1.1 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip nat inside
zone-member security INSIDE

media-type rj45
negotiation auto
no mop enabled
ip virtual-reassembly
ip virtual-reassembly-out

interface Dialer0
description --- FTTP PPPoE ---
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip nat outside
zone-member security OUTSIDE
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname <removed>
ppp chap password 7 <removed>
ppp ipcp dns request accept
ppp ipcp route default
ip virtual-reassembly max-reassemblies 256

[Rob Ingram]

Hi @ddolbel 

If you want to block ping to your WAN interface (Dialer0) then you need a ZBFW zone-pair from OUTSIDE to "self" zone. The "self" zone applies to the router's interfaces. The INSIDE zone is from clients behind the router on the inside of the network.

[ddolbel]

Hi @Rob Ingram thanks for your reply.. you have kinda lost me here the router i'm using has 2 interfaces... it sounds like i need a third zone and another interface? 

[Rob Ingram · Accepted solution]

@ddolbel 

You don't create the "self" zone, it already exists. The "self" zone controls traffic "to"/"from" any traffic originating or destined to the routers interface, as opposed to "through" the router. The "self" zone would control VPNs terminating against the router's interface, SSH to the router itself, pinging the router's interface etc.

You've created OUTSIDE and INSIDE zones and applied those to your interfaces. Your zone-pairs will control traffic "through" the router from OUTSIDE to INSIDE and vice versa.

More information on self zone

https://community.cisco.com/t5/security-documents/zbfw-self-zone-integration/ta-p/3154572

https://community.cisco.com/t5/network-security/zbfw-self-zone-and-default-zone/td-p/4104165

[ddolbel]

Hi @Rob Ingram 

Thanks for your reply and the links, I have had a look and tried the following

class-map type inspect match-all OUTSIDE-TO-SELF-ICMP-POLICY
match protocol icmp

policy-map type inspect OUTSIDE-TO-SELF
class type inspect OUTSIDE-TO-SELF-ICMP-POLICY
inspect
class class-default

policy-map type inspect SELF-TO-OUTSIDE
class type inspect OUTSIDE-TO-SELF-ICMP-POLICY
inspect
class class-default

zone-pair security OUTSIDE-TO-SELF source OUTSIDE destination self
service-policy type inspect OUTSIDE-TO-SELF
zone-pair security SELF-TO-OUTSIDE source self destination OUTSIDE
service-policy type inspect SELF-TO-OUTSIDE

however outside can still ping my wan interface

[Rob Ingram]

@ddolbel use "drop" instead of "inspect".

[ddolbel]

@Rob Ingram 

ah ha!! 

policy-map type inspect OUTSIDE-TO-SELF
class type inspect OUTSIDE-TO-SELF-ICMP-POLICY
drop
class class-default

wan is now timing out nice!!

do i need to do the same for this policy?

policy-map type inspect SELF-TO-OUTSIDE
class type inspect OUTSIDE-TO-SELF-ICMP-POLICY
inspect
class class-default

[Rob Ingram]

@ddolbel 

Not necessarily, if you configure drop on SELF-TO-OUTSIDE, then the router won't be able to ping outbound.

[ddolbel]

@Rob Ingram 

Thanks

I have lost the ability to ping inside sites, would i be right in saying that i need to create a new zone pair self-to-inside?

[Rob Ingram]

@ddolbel 

Correct, As soon as you configure one zone-pair that involves the Self-Zone traffic from any zone to the Self or from the Self to any zone will be filtered. So you'll also need to create another for INSIDE to self.

[ddolbel]

@Rob Ingram 

thanks for the info, I have created the new zones

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

policy-map type inspect INSIDE-TO-SELF
class type inspect INSIDE-TO-SELF
inspect
class class-default

policy-map type inspect SELF-TO-INSIDE
class type inspect SELF-TO-INSIDE
inspect
class class-default

zone-pair security INSIDE-TO-SELF source INSIDE destination self
service-policy type inspect INSIDE-TO-SELF

zone-pair security SELF-TO-INSIDE source self destination INSIDE
service-policy type inspect SELF-TO-INSIDE

ip access-list extended SELF-TO-INSIDE
10 permit ip any any

ip access-list extended INSIDE-TO-SELF
10 permit ip any any

now my ipsec tunnels have gone down.

[Rob Ingram]

@ddolbel Yes of course they would, now that you've referenced the self zone in a zone-pair you have to control traffic in and outbound. You'll need to explictly permit the traffic you want to terminate on the router, such as IKE, IPSec etc.

[ddolbel]

@Rob Ingram 

i figured that so i created the following

class-map type inspect match-any OUTSIDE-TO-SELF-REMOTE-SITES-POLICY
match access-group name OUTSIDE-TO-SELF-REMOTE-SITES

policy-map type inspect OUTSIDE-TO-SELF
class type inspect OUTSIDE-TO-SELF-ICMP-POLICY
drop
class type inspect OUTSIDE-TO-SELF-REMOTE-SITES-POLICY
inspect
class class-default

ip access-list extended OUTSIDE-TO-SELF-REMOTE-SITES
10 remark Allow Inbound Connections
10 remark VPN Connection
10 permit gre any any
20 permit udp any any eq non500-isakmp
30 permit udp any any eq isakmp
40 permit esp any any
50 permit ahp any any

**bleep** what a head ache... i used to have 10 lines for ip inspect now i have over 40

looks like i'm up and running, thanks for the assist @Rob Ingram 

[ddolbel]

@Rob Ingram 

not sure why but my asterisk server keep losing registration to external sip providers.

i'm currently running ios 17.3.4a(MD) i checked the release notes and couldn't see any caveats relating to sip