Cart
One of the CCIE Security v3.0 topics that often gives candidates a run for their money is the Cisco IOS Zone Based Firewalls. It’s not that the configuration is all that difficult, rather that when you finally get things up and running you forget that its there and it breaks other connections.
In this post we are going to cover three things.
- The basic configuration of a Zone Based Firewall
- How to monitor the drops
- How to think like a CCIE —> You’re going to do this part!
Lets begin with the configuration. For this simple example I’ve used gns3 to create a three interface firewall. We have an inside zone, outside zone, and a dmz zone. We will have the goal of allowing TCP and UDP connections from inside to outside as wekk as dmz to outside, http from the outside to the dmz along with any other “required” connections from the outside to the inside.
The starting configurations are pretty straigt forward but Ill show them in case you want to recreate the scenario. On thing I should mention is that some confuguraiton may be added later based on out diagram. With that said, here are the configs:
R1:
R1#sh run Building configuration... Current configuration : 922 bytes ! version 12.4 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet1/0 ip address 10.2.1.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet1/1 no ip address shutdown duplex auto speed auto ! router eigrp 100 network 1.0.0.0 network 10.0.0.0 no auto-summary ! ! ! line con 0 exec-timeout 0 0 logging synchronous stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! ! end R1#
R2:
R2#sh run Building configuration... Current configuration : 1098 bytes ! version 12.4 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet1/0 ip address 10.2.1.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet1/1 ip address 10.2.3.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet2/0 ip address 10.2.4.2 255.255.255.0 duplex auto speed auto ! router eigrp 100 network 2.0.0.0 network 10.0.0.0 no auto-summary ! ! line con 0 exec-timeout 0 0 logging synchronous stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! ! end R2#
R3:
R3#sh run Building configuration... Current configuration : 922 bytes ! version 12.4 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! ! interface FastEthernet1/0 ip address 10.2.3.3 255.255.255.0 duplex auto speed auto ! router eigrp 100 network 3.0.0.0 network 10.0.0.0 no auto-summary ! ! line con 0 exec-timeout 0 0 logging synchronous stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! ! end R3#
R4:
R4#sh run *Jan 6 15:10:12.431: %SYS-5-CONFIG_I: Configured from console by console R4#sh run Building configuration... Current configuration : 922 bytes ! version 12.4 ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface FastEthernet1/0 ip address 10.2.4.4 255.255.255.0 duplex auto speed auto ! router eigrp 100 network 4.0.0.0 network 10.0.0.0 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! ! end R4#
A word of caution- if you do this on your own- test connectivity before moving on. I’ve already done it so we will continue on.
Now the next step would be to define an access-list to allow http traffic into the DMZ web server. All of this configuration will be done on R2:
Ip access-list extended OUT_IN Permit tcp any host 3.3.3.3 eq 80
Next create the class-maps that will reference the traffic in the ACL and the protocol traffic to inspect.
Class-map type inspect match-any INSIDE Match Protocol TCP Match Protocol UDP Class-map type inspect match-all OUTSIDE Match Protcol http Match access-g name OUT_IN Class-map type inspect match-any DMZ Match Protocol TCP Match Protocol UDP
Next we want to define the policy for this traffic with a policy map:
Policy-map type inspect IN_OUT Class INSIDE Inspect Policy-map type inspect OUT_IN Class OUTSIDE inspect Policy-map type inspect DMZ_OUT Class DMZ inspect Policy-map type inspect OUT_DMZ Class OUTSIDE inspect
Next we create the zones:
Zone security inside Zone security outside Zone security dmz
Next the zone-pairs which essentially defines directionality of traffic:
Zone-pair security IN->OUT source inside destination outside Policy-map type inspect IN_OUT Zone-pair security OUT->IN source outside destination inside Policy-map type inspect OUT_IN Zone-pair security DMZ->OUT source dmz destination outside Policy-map type inspect DMZ_OUT Zone-pair security OUT->DMZ source outside destination dmz Policy-map type inspect OUT_DMZ
Now assign them to the interfaces:
Interface f2/0 Zone-member security inside Interface f1/0 Zone-member security outside Interface f1/1 Zone-member security dmz
At this point we are pretty close to testing. First lets enable telnet on all the routers and the http server on R3.
All routers:
Line vty 0 15 password ipexpert login
R3:
Ip http server enable
Now if all goes according to plan we should be able to telnet from R4 to R1 and R3 to R1 but not from R1 to R3 or R4. We should, however, be able to telnet to R3 on port 80, thus testing the http access.
So we test on R4:
R4#telnet 1.1.1.1 Trying 1.1.1.1 ... Open User Access Verification Password: R1>
And next on R3:
R3#telnet 1.1.1.1 Trying 1.1.1.1 ... Open User Access Verification Password: R1>
For now we can leave those sessions connected. Next lets try to telnet from the outside R1 to R3 and R4. Before we do that lets turn on a handy little command on R2:
R2(config)#ip inspect log drop-pkt
Now, when packets are dropped we should see them. So lets go back to R1 and test:
R1#telnet 4.4.4.4 Trying 4.4.4.4 ... % Connection timed out; remote host not responding R1#telnet 3.3.3.3 Trying 3.3.3.3 ... % Connection timed out; remote host not responding
We should now see the drops on R2:
*Jan 6 17:31:55.575: %FW-6-DROP_PKT: Dropping Other session 10.2.1.1:60632 4.4.4.4:23 on zone-pair OUT->IN class class-default due to DROP action found in policy-map with ip ident 0 R2# *Jan 6 17:32:51.143: %FW-6-LOG_SUMMARY: 4 packets were dropped from 10.2.1.1:60632 => 4.4.4.4:23 (target:class)-(OUT->IN:class-default) R2# *Jan 6 17:33:27.135: %FW-6-DROP_PKT: Dropping Other session 10.2.1.1:46475 3.3.3.3:23 on zone-pair OUT->DMZ class class-default due to DROP action found in policy-map with ip ident 0 R2# *Jan 6 17:33:51.143: %FW-6-LOG_SUMMARY: 4 packets were dropped from 10.2.1.1:46475 => 3.3.3.3:23 (target:class)-(OUT->DMZ:class-default)
Remember we were going to be allowing http into the DMZ so lets test that from R1:
R1#telnet 3.3.3.3 80 Trying 3.3.3.3, 80 ... Open
Now that was successful but lets verify on R2 by looking at the sessions:
R2#sh policy-map type inspect zone-pair OUT->DMZ sessions policy exists on zp OUT->DMZ Zone-pair: OUT->DMZ Service-policy inspect : OUT_DMZ Class-map: OUTSIDE (match-all) Match: protocol http Match: access-group name OUT_IN Inspect Number of Established Sessions = 1 Established Sessions Session 676863C0 (10.2.1.1:25424)=>(3.3.3.3:80) http:tcp SIS_OPEN Created 00:00:48, Last heard 00:00:48 Bytes sent (initiator:responder) [0:0] Class-map: class-default (match-any) Match: any Drop 12 packets, 288 bytes R2#sh policy-map type inspect zone-pair IN->OUT sessions policy exists on zp IN->OUT Zone-pair: IN->OUT Service-policy inspect : IN_OUT Class-map: INSIDE (match-any) Match: protocol tcp 3 packets, 72 bytes 30 second rate 0 bps Match: protocol udp 0 packets, 0 bytes 30 second rate 0 bps Inspect Number of Established Sessions = 1 Established Sessions Session 67685FC0 (10.2.4.4:51576)=>(1.1.1.1:23) tcp SIS_OPEN Created 00:07:26, Last heard 00:07:23 Bytes sent (initiator:responder) [34:71] Class-map: class-default (match-any) Match: any Drop 0 packets, 0 bytes R2#sh policy-map type inspect zone-pair DMZ->OUT sessions policy exists on zp DMZ->OUT Zone-pair: DMZ->OUT Service-policy inspect : DMZ_OUT Class-map: DMZ (match-any) Match: protocol tcp 7 packets, 168 bytes 30 second rate 0 bps Match: protocol udp 0 packets, 0 bytes 30 second rate 0 bps Inspect Number of Established Sessions = 1 Established Sessions Session 676861C0 (10.2.3.3:18939)=>(1.1.1.1:23) tcp SIS_OPEN Created 00:07:06, Last heard 00:07:03 Bytes sent (initiator:responder) [34:71] Class-map: class-default (match-any) Match: any Drop 0 packets, 0 bytes R2#
Now lets take this back to the real lab exam since this is a topic that you may be tested on and we want you to think like you would in the actual lab. What is missing in this configuration? Would the above configuration get you the points? Submit your answer by commenting and we will review it in the next post.
Brandon Carroll – CCIE #23837
Senior Technical Instructor – IPexpert
Mailto: bcarroll@ipexpert.com
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
In this task you forgot the part about “allowing any other required connections” you broke your later VPN configuration by not allowing anything but HTTP from the outside. You need to allow UDP port 500 and possibly 4500 (for NAT) from Router1 to Router3.
You need the following configuration if sourcing the VPN from the loopback interface and this is assuming no NAT is being configured.
Class-map type inspect match-all OUTSIDE
match protocol http
match protocol udp
match access-g name OUT_IN
Ip access-list extended OUT_IN
permit tcp any host 3.3.3.3 eq 80
permit udp host 1.1.1.1 host 3.3.3.3 eq 500
I’ll have a shot at this – don’t have any access to a router, so all off the top of my head! :-)
Assuming that the IPSEC tunnel is just using ESP, we must allow the non-IP IPSEC traffic (ESP), to pass in and out. We can also inspect the isakmp traffic coming in. The outbounch isakmp is inspected with already,
!- define the isakmp traffic coming in.
ip access-list ex 100
per udp host 1.1.1.1 eq 500 host 3.3.3.3 eq 500
class-map isakmp_i
match ip access-group 100
!- esp out to in
ip access-list ex 101
permit esp host 1.1.1.1 host 3.3.3.3
class-map esp_in_out
match ip access-group 101
!- esp in to out
ip access-list ex 102
permit esp host 3.3.3.3 host 1.1.1.1
class-map esp_out_in
match ip access-group 102
!- add this to the already configured policy map
Policy-map type inspect OUT_IN
class esp_out_in
pass
Policy-map type inspect IN_OUT
class esp_in_out
pass
Also, EIGRP traffic will be dropped since you are missing a policy from each zone to the router itself. zones to self and also self to zones.
PaulI believe your are wrong amigo. ;-)
There’s no self zone defined, traffic is implicitly allow to the box unless a self zone is defined.
Brandon – Please let us know the solution mate! :-)
Hey guys,
Check this out:
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a008060f6dd.html#wp1191103
The “self” zone allows all connections to and from the router.
Hello, i don’t understand why your are allowing the inspection of HTTP from OUTSIDE to INSIDE since we want only http traffic from OUTSIDE to DMZ?
Thanks for your reply.
!
Class-map type inspect match-all OUTSIDE
Match Protcol http
Match access-g name OUT_IN
!
Policy-map type inspect OUT_IN
Class OUTSIDE
inspect
!
Zone-pair security OUT->IN source outside destination inside
Policy-map type inspect OUT_IN
!
I did this to make sure its going to match the http protocol as well as the ACL. Note that I used a match-all in the class-map. So you cant get to the inside if you dont meet both the ACL and the http protocol. The ACL only matches traffic to the DMZ.
Regards,
Brandon
I’ve had a lot of issues getting a router in GNS3 that supports zone-based firewall. Which routers are you using in the lab, and what version of IOS. I know 12.4 is required, and like the advanced ip services suite… but every router in GNS3 I’ve tried does not support this feature set (I’m loosing my mind a little lol). Please help.
Minimum hardware for GNS3 is recommended using the 3725 with IP Security 12.4(15)T
If you can use the 7204VXR they are great you can run 12.4(24)T3 on them.
Have you used our instructions?
http://blog.ipexpert.com/2010/07/05/gns3-on-ubuntu-910-the-ipexpert-way/
http://blog.ipexpert.com/2010/03/31/gns3-on-windows-7-the-ipexpert-way/
Thanks Terry! Everything seems to working, and when IOS help revealed class-map type ?
match-any
match-all
TYPE!!!
Awh, victory at last. My one complaint about GNS3 is it’s massive cpu/memory hog lol. I’ve got a core i7 and 4GB of ram… but if I load 4 or 5 routers in and get them working dynamips just crashes or GNS3 hangs lol.
LOL! Sorry Tyson, I have no idea why I called you ‘Terry’… perhaps the strong combination of lacking sleep and watching Reno 911 while I’m working. Anyway, thanks a million!