Zone based FW and NATs

notgoing2fail

Hey guys, I'm going to try to lab this up today, but was wondering if I could get a little "hint" in the direction...

So ACL's can be applied to class-maps. When creating NAT's, whether pooled, PATs or 1-to-1, how does that fit in the overall makeup of ZFW?

Do the "ip nat inside/outside" command still get issued on the interface or does it get applied somehow to the zone or policy?

I see that you still have to go to the interface and apply the interface to a zone-member. So does nothing really change at all in terms of configuring the inside/outside interface? Does it still get applied physically to the interface?

notgoing2fail

ok, I've answered my own question after labbing this up.

It appears you do need to issue the IP NAT inside/outside directly to the interfaces instead of to zones. This really helps conceptually clear things up for me...

ilcram19-2

notgoing2fail wrote: »

ok, I've answered my own question after labbing this up.

It appears you do need to issue the IP NAT inside/outside directly to the interfaces instead of to zones. This really helps conceptually clear things up for me...

the thing is you need to create a to selfzone for the router otherwise all traffic is going to be allowed from the outside like ping, isakmp telnet, ssh, and any other nat or pat translation that you have

notgoing2fail

ilcram19-2 wrote: »

the thing is you need to create a to selfzone for the router otherwise all traffic is going to be allowed from the outside like ping, isakmp telnet, ssh, and any other nat or pat translation that you have

Are you talking about traffic coming in from the OUTSIDE originally or any traffic originally initiated from the INSIDE and then coming from the OUTSIDE?

In my class maps I only have this allowed:

match protocol icmp
match protocol http
match protocol dns


I don't have any selfzone created, I suppose I should look into doing that....

ilcram19-2

nope the router it self is not protected, it has a default zone called self that needs to be configure as well and since the outside ip is of the router NAT will still work with no probelm

class-map type inspect match-any to-self-in
match protocol icmp
match access-group name outside_in

policy-map type inspect to-self-policy
class type inspect to-self-in
inspect ZFW
class class-default
drop

zone-pair security internet-self source internet destination self
service-policy type inspect internet-self-policy

ip access-list extended outside_in
permit udp host 166.135.101.162 host 209.12.201.194 eq isakmp
permit esp host 166.135.101.162 host 209.12.201.194
permit udp host 138.113.137.146 host 209.12.201.194 eq isakmp
permit esp host 138.113.137.146 host 209.12.201.194
permit tcp host 138.113.137.146 host 209.12.201.194 eq 65432
permit icmp host 138.113.137.146 host 209.12.201.194
permit tcp host 138.113.137.146 host 209.12.201.194 eq 22
permit tcp host 138.113.137.146 host 209.12.201.194 eq 3389
permit ip host 216.99.133.100 host 209.12.201.194

otherwise everything would be allow to selft (router) also you need to do that from inside to self, dmz to self etc

ilcram19-2

"traffic in any zone flowing directly to the addresses of the router’s interfaces is implicitly allowed"

check this link out maybe it can explain better
Zone-Based Policy Firewall Design and Application Guide - Cisco Systems

notgoing2fail

Fantastic! Thank you so much, I will try out the self zones in a minute as well as read the link. I do have a quick question for you regarding NAT and ACL's.

In my class-map, as you can see above, I do not have "match access-group 101" applied.

The 101 ACL permits my private hosts to "any".

Yet my inside hosts were able to traverse the zones and get to the internet.

Why is that? I thought that all traffic traversing the zones would need to have rules in the class-map no?

notgoing2fail

I got an invalid parameter-map when trying to configure the policy. Could you show me how your paramet-map is configured?


RTR-1811W(config-pmap-c)#inspect ZFW
%Invalid parameter-map name

RTR-1811W(config-pmap-c)#%Parameter-map ZFW not found or does not match inspect type

ilcram19-2

notgoing2fail wrote: »

I got an invalid parameter-map when trying to configure the policy. Could you show me how your paramet-map is configured?


RTR-1811W(config-pmap-c)#inspect ZFW
%Invalid parameter-map name

RTR-1811W(config-pmap-c)#%Parameter-map ZFW not found or does not match inspect type

oh that is to audit log and keep track of the connections, tcp settings etc you can just do inspect the parametter map was configure like this

parameter-map type inspect ZFW
audit-trail on
tcp idle-time 120
tcp synwait-time 120
sessions maximum 15000

then you can add it

policy-map type inspect to-self-policy
class type inspect to-self-in
inspect ZFW
class class-default
drop

ilcram19-2

notgoing2fail wrote: »

Fantastic! Thank you so much, I will try out the self zones in a minute as well as read the link. I do have a quick question for you regarding NAT and ACL's.

In my class-map, as you can see above, I do not have "match access-group 101" applied.

The 101 ACL permits my private hosts to "any".

Yet my inside hosts were able to traverse the zones and get to the internet.

Why is that? I thought that all traffic traversing the zones would need to have rules in the class-map no?

did you created the zone and applied to the interfaces?

zone security internet
description "Unsecure Zone (Internet)"

zone security inside
description "trusted"

interface FastEthernet4
zone-member security internet


interface Vlan1
zone-member security inside


here are the rules

Rules For Applying Zone-Based Policy Firewall
Router network interfaces’ membership in zones is subject to several rules that govern interface behavior, as is the traffic moving between zone member interfaces:

•A zone must be configured before interfaces can be assigned to the zone.

•An interface can be assigned to only one security zone.

•All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.

•Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

•In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

•The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

•Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.

•Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.

•If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.

•From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).

•The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

notgoing2fail

ilcram19-2 wrote: »

did you created the zone and applied to the interfaces?

zone security internet
description "Unsecure Zone (Internet)"

zone security inside
description "trusted"

interface FastEthernet4
zone-member security internet


interface Vlan1
zone-member security inside


here are the rules........

Yup I pretty much understand the rules for the most part. What I did was a constant ping to google.

As soon as I assigned zones to the interfaces, the pings stopped. As soon as I added:

match protocol icmp
match protocol dns

The pings started to work again, well, of course after I applied the policy map and created the zone pairs...


I guess I am confused about "match access-group" from within the class-map object.

I thought that this command needed to be added to the class-map inspection to be part of the policy so that the policy-map can allow traffic defined in the ACL. It appears that's not the case.

I'm reading the link you provided to get a better understanding of when to apply it. I need to re-read it because so far it kinda looks like it is trying to say you need an ACL applied to a class-map/policy-map in order for traffic to communicate with other zones, which is what I had originally thought, but I must be interpreting the doc wrong....

notgoing2fail

Ok, I understand the "match access-group 101" command now.

Basically I already had matches that allowed my internet to work. So when adding this ACL it made no difference.

When I took everything out, and only included "match access-group 101" I was then able to see the difference.

The ACL which is a "permit ip 172.16.0.0 0.0.255.255 any" basically allows ALL traffic of any kind through. So I suppose creating the ACL would allow more granular control over the type of traffic allowed through, AND it would need to be applied at the top of the list just like how you normally would want more specific ACL's to be up on top...

So in a way, instead of having:

match protocol http
match protocol https
match protocol icmp
match protocol dns


I can put all that in my extended ACL, and then in the class-map, just apply one command to it.

I'm sure there are some pros and cons to doing it this way....

Some con's, the ACL doesn't provide the deep inspection that you could get from using ZFW....

ilcram19-2

notgoing2fail wrote: »

Some con's, the ACL doesn't provide the deep inspection that you could get from using ZFW....

i use that mainly for audit trail and to have a syslog entry so i can see where packets are coming and going to

notgoing2fail

ilcram19-2 wrote: »

i use that mainly for audit trail and to have a syslog entry so i can see where packets are coming and going to

Yeah, when I configured the paramater map you gave me, I was getting tons of log entries!!

It's too bad no one really took part in my poll...I really would like to know how many people really use ZFW...

Cause you know, Cisco makes all of their features sound like the greatest invention ever....

CRS-3 anyone?

ilcram19-2

i know is a pain at first to configure and deploy specially when you add content filtering and url filtering that looks something like this, is pretty cool once is done but try to do it for 3 or 4 different zones

parameter-map type inspect global

parameter-map type urlfpolicy local local-url-allow-vlan3


parameter-map type urlfpolicy trend tm-parameters-for-vlan3-policy
max-resp-pak 100
allow-mode on
truncate hostname
block-page message "You cannot see this page"

parameter-map type urlfpolicy trend trend-para-category-deny-vlan3

parameter-map type urlfpolicy trend trend-para-reputation-deny-vlan3

parameter-map type urlfpolicy trend tm-parameters-for-vlan1-policy
max-request 2000
allow-mode on
truncate hostname
block-page message "You cannot see this page"


class-map type urlfilter trend match-any trend-rep-deny-class-class-vlan3
match url reputation ADWARE
match url reputation DIALER
match url reputation DISEASE-VECTOR
match url reputation HACKING
match url reputation PASSWORD-CRACKING-APPLICATIONS
match url reputation PHISHING
match url reputation POTENTIALLY-MALICIOUS-SOFTWARE
match url reputation SPYWARE
match url reputation VIRUS-ACCOMPLICE
class-map type urlfilter trend match-any trend-category-deny-class-vlan3
match url category Adult-Mature-Content
match url category Gambling
match url category Marijuana
match url category Nudity
match url category Pornography
match url category Violence-hate-racism
match url category Abortion
match url category Activist-Groups
match url category Alternative-Journals
match url category Alcohol-Tobacco
match url category Auctions
match url category Brokerage-Trading
match url category Chat-Instant-Messaging
match url category Computers-internet
match url category Cookies
match url category Cult-Occult
match url category Email
match url category Entertainmemt
match url category For-Kids
match url category Games
match url category Humor-jokes
match url category Illegal-Drugs
match url category Illegal-Questionable
match url category Internet-Radio-and-TV
match url category Internet-Telephony
match url category Pay-to-surf
match url category Peer-to-Peer
match url category Personal-Network-Storage
match url category Personal-Websites
match url category Personals-Dating
match url category Proxy-Avoidance
match url category Remote-access-programs


policy-map type inspect urlfilter trend-url-policy-vlan3
parameter type urlfpolicy trend tm-parameters-for-vlan3-policy
class type urlfilter trend-url-allow-class-vlan3
allow
log
class type urlfilter trend trend-category-deny-class-vlan3
reset
log
class type urlfilter trend trend-rep-deny-class-class-vlan3
reset
log

notgoing2fail

Holy bajeezus!!!

Yeah that's quite a ZFW config there. And I assume that's only a piece of it.

As a former programmer, I can see the advantage of it, you can reuse class-maps or quickly add items to the class-maps etc.....
You can compare it "kind of" to named ACL's where you don't have to redo the whole ACL for additions/deletions...

I can see how it can be more "dynamic" in nature...and definitely provides more granular inspection then just regular ACL's...

But I am also beginning to think that ZFW is a lot like VPN's, in the sense that unless you're working on it daily, you're best bet is to write it down, create a step by step guide to reference....

There's just a lot of "moving parts" involved.....

One quick question, can the "zone" be applied to any interface whether physical or virtual? I am assuming you can create a VLAN and apply the ZFW to an SVI correct?

So if you really want to get crazy, you can have a zone for each VLAN right?

Or is that the entire purpose of ZFW in the first place and I just completely missed the point. LOL...

ilcram19-2

yea i've done on physical interfaces, VTI, GRE interface, vlans, subinterface etc

notgoing2fail

ilcram19-2 wrote: »

yea i've done on physical interfaces, VTI, GRE interface, vlans, subinterface etc

Hmmm...what is the difference between VTI and GRE interface?

ilcram19-2

notgoing2fail wrote: »

Hmmm...what is the difference between VTI and GRE interface?

VTI my concept of vti is the follwing: an encrypted point to point link
here is the cisco
VIRTUAL TUNNEL INTERFACES

Cisco® IPSec VTIs are a new tool that customers can use to configure IPSec-based VPNs between site-to-site devices. IPSec VTI tunnels provide a designated pathway across a shared WAN and encapsulate traffic with new packet headers, which helps to ensure delivery to specific destinations. The network is private because traffic can enter a tunnel only at an endpoint. In addition, IPSec provides true confidentiality (as does encryption) and can carry encrypted traffic.
Configuring a Virtual Tunnel Interface with IP Security [IPSec Negotiation/IKE Protocols] - Cisco Systems

and a GRE interface you actually specified gre encapsulation on the tunnel interface and add a crypto map

generic routing encapsulation. Tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork

hope that helps

notgoing2fail

ilcram19-2 wrote: »

VTI my concept of vti is the follwing: an encrypted point to point link
here is the cisco
VIRTUAL TUNNEL INTERFACES

Cisco® IPSec VTIs are a new tool that customers can use to configure IPSec-based VPNs between site-to-site devices. IPSec VTI tunnels provide a designated pathway across a shared WAN and encapsulate traffic with new packet headers, which helps to ensure delivery to specific destinations. The network is private because traffic can enter a tunnel only at an endpoint. In addition, IPSec provides true confidentiality (as does encryption) and can carry encrypted traffic.
Configuring a Virtual Tunnel Interface with IP Security [IPSec Negotiation/IKE Protocols] - Cisco Systems

and a GRE interface you actually specified gre encapsulation on the tunnel interface and add a crypto map

generic routing encapsulation. Tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork

hope that helps

Thanks, I started reading up on VTI configuration after you mentioned it earlier up. It is interesting indeed and I hope to do some lab time with it. There seems to be so many ways to provide "protected" data across an internetwork nowadays it's hard to get your head wrapped around them. Best thing is do each one at a time....

I do like that there are no crypto maps with VTI's..the tunnel config seems to be pretty straight forward...

ilcram19-2

yea the ipsec profile aplied to the interface provide the protection.
thats why i use routers instead of ASA more flexible and i dont use site to site ipsec
i use more of VTI's,gre over ipsec, DMVPN, i dont have any limitations allows me to get to any point of my network by using 1 tunnel instead of having ipsec tunnels to each point
and only limiting to ip traffic.

notgoing2fail

ilcram19-2 wrote: »

yea the ipsec profile aplied to the interface provide the protection.
thats why i use routers instead of ASA more flexible and i dont use site to site ipsec
i use more of VTI's,gre over ipsec, DMVPN, i dont have any limitations allows me to get to any point of my network by using 1 tunnel instead of having ipsec tunnels to each point
and only limiting to ip traffic.

It seems by using VTI's you can also use OSPF and other link-state type protocols now right? As opposed to using your normal site-to-site VPN that may break up the use of OSPF, IS-IS...

I could be wrong, just a thought.....and I'm not sure if one would really want to such a think anyways....

I can't wait to start looking into CCDA so I can get an overall sense of proper design and techniques....

Just not enough time in the day to read and ABSORB!!!