Zone based FW and NATs

notgoing2failnotgoing2fail Member Posts: 1,138
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?

Comments

  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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-2ilcram19-2 Banned Posts: 436
    "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
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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?
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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-2ilcram19-2 Banned Posts: 436
    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.
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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....
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    yea i've done on physical interfaces, VTI, GRE interface, vlans, subinterface etc
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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-2ilcram19-2 Banned Posts: 436
    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.
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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!!!
Sign In or Register to comment.