Zone Based Firewall Transparent Mode

Cisco’s zone based firewall is normally used with layer 3 interfaces but you can also use it as a transparent firewall. If you have no idea what zone based firewalls are then I suggest you first take a look at my basis ZBF configuration example. If you haven’t configured layer 2 bridging before then you should start with the transparent IOS firewall example. Having said that, let’s configure a Zone based firewall in transparent mode. This is the topology that I will be using:

Above we have 3 routers. R1 and R3 are in the same layer 2 segment because we’ll configure R2 to bridge the FastEthernet 0/0 and 0/1 interfaces. Once this is done we’ll configure the Zone Based Firewall. I will use a very simple example, by default all inter-zone traffic is denied. I want to configure R2 so that it will permit only ICMP traffic from R1 to R3 (and the return traffic). Let’s get started!

Configuration

First we’ll configure bridging:

R2(config)#bridge crb 
R2(config)#bridge 1 protocol ieee 

R2(config)#interface fastEthernet 0/0
R2(config-if)#bridge-group 1

R2(config)#interface fastEthernet 0/1
R2(config-if)#bridge-group 1

I don’t need a layer 3 interface on R2 so we’ll go for concurrent routing and bridging with IEEE spanning-tree. The two FastEhernet interfaces have been added to the bridge group.

If you decide to use bridge irb, the layer 3 bridge interface will automatically belong to the ZBF self zone.

I will create a LAN and WAN zone. R1 will be in the LAN zone and R3 in the WAN zone. We’ll also add the interfaces to the correct zone and create a zone pair for traffic from our LAN to the WAN.

R2(config)#zone security LAN
R2(config)#zone security WAN

R2(config)#interface fastEthernet 0/0
R2(config-if)#zone-member security LAN

R2(config)#interface fastEthernet 0/1
R2(config-if)#zone-member security WAN  

R2(config)#zone-pair security LAN-TO-WAN source LAN destination WAN

With the zones in place, we can create a security policy. We’ll use NBAR to match on ICMP traffic and create a policy-map that uses the inspect rule:

R2(config)#class-map type inspect ICMP
R2(config-cmap)#match protocol icmp

R2(config)#policy-map type inspect LAN-TO-WAN 
R2(config-pmap)#class ICMP
R2(config-pmap-c)#inspect

Last but not least we have to attach that policy-map to the zone pair:

R2(config)#zone-pair security LAN-TO-WAN
R2(config-sec-zone-pair)#service-policy type inspect LAN-TO-WAN

That’s everything we have to configure. Time to find out if everything is working…

Verification

The first thing you should do is check if your bridge works:

R2#show bridge 1

Total of 300 station blocks, 298 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address       Action   Interface       Age   RX count   TX count
c202.23f6.0000   forward   FastEthernet0/1   0          5          4
c200.23f6.0000   forward   FastEthernet0/0   0         11         10

Bridging on R2 seems to be working, it has learned the MAC addresses of R1 and R3. We’ll send some pings from R3 to R1 to see if our ZBF transparent firewall is working:

R3#ping 192.168.13.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

I can’t ping which is as expected because all inter-zone traffic is dropped by default. Let’s try to ping from R1 to R3:

R1#ping 192.168.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

R2#show policy-map type inspect zone-pair 
 Zone-pair: LAN-TO-WAN

  Service-policy inspect : LAN-TO-WAN

    Class-map: ICMP (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [1:29]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [1:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:0]
        Last session created 00:00:04
        Last statistic reset never
        Last session creation rate 1
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

That’s working fine! If you look at the output above you can see that ICMP packets are permitted. I hope this basic example helps you to understand how to configure the zone based firewall in transparent mode.

hostname R1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.13.1 255.255.255.0
!
end

hostname R2
!
ip cef
!
class-map type inspect match-all ICMP
 match protocol icmp
!
policy-map type inspect LAN-TO-WAN
 class type inspect ICMP
  inspect
 class class-default
  drop
!
zone security LAN
zone security WAN
zone-pair security LAN-TO-WAN source LAN destination WAN
 service-policy type inspect LAN-TO-WAN
!
bridge crb
!
interface FastEthernet0/0
 no ip address
 zone-member security LAN
 bridge-group 1
!
interface FastEthernet0/1
 no ip address
 zone-member security WAN
 bridge-group 1
!
bridge 1 protocol ieee
!
end

hostname R3
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.13.3 255.255.255.0
!
end

If you have any questions feel free to leave a comment!

Zone Based Firewall Configuration Example

Zone Based Firewall is the most advanced method of a stateful firewall that is available on Cisco IOS routers. The idea behind ZBF is that we don’t assign access-lists to interfaces but we will create different zones. Interfaces will be assigned to the different zones and security policies will be assigned to traffic between zones. To show you why ZBF is useful, let me show you a picture:

Above you see a small network that has a LAN, DMZ and WAN with two ISPs. Let’s say our security policy looks like this:

• Traffic from the LAN is allowed to the WAN but only to HTTP and HTTPS servers.
• Traffic from the LAN is allowed to the DMZ unrestricted.
• Traffic from the DMZ is not allowed to the LAN.
• Traffic from the DMZ is allowed to the WAN but only for the DNS and HTTP servers.
• Traffic from the WAN is allowed to the LAN, but only to a FTP server.

If you want to achieve this using access-lists, you’ll have to create multiple access-lists and attach them to different interfaces inbound and/or outbound. To say the least, it becomes an administrative pain to do this. It’s possible but annoying.

With the zone based firewall, we won’t apply the security policies to the interfaces but to security zones. Interfaces will become members of the different zones. Here’s an example of the topology above with zones:

Above you see 3 zones; LAN, WAN and DMZ. The interfaces are assigned to the correct zone and now we can apply security policies to traffic between zones. For example:

• LAN to WAN
• LAN to DMZ
• WAN to LAN
• WAN to DMZ
• DMZ to WAN
• DMZ to LAN

To create a security policy for traffic between zones we have to create a zone pair. We have to configure zone pairs ourselves and apply a security policy to them to determine what traffic is permitted from one zone to another. All security policies are attached to the zone pairs. Now you have an idea what a zone based firewall is, let me show you how to configure this.

Configuration

We will use the following topology:

Above you see 3 routers and two zones called LAN and WAN. We will configure ZBF on R2. For connectivity, I’ll create a static route on R1 and R3 that points to R2:

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

R3(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2

Now we can configure the firewall.

Configure the Zones

First we will create the two zones, we only have two of them:

R2(config)#zone security LAN
R2(config)#zone security WAN

Secondly we will assign the interfaces to the correct zone:

R2(config)#interface fastEthernet 0/0
R2(config-if)#zone-member security LAN

R2(config)#interface fastEthernet 0/1 
R2(config-if)#zone-member security WAN

Let’s verify the configuration of the zones:

R2#show zone security 
zone self
  Description: System defined zone

zone LAN
  Member Interfaces:
    FastEthernet0/0

zone WAN
  Member Interfaces:
    FastEthernet0/1

The zones are active and interfaces have been assigned to them, now we can create the zone pairs.

Configure the Zone Pairs

R2(config)#zone-pair security LAN-TO-WAN source LAN destination WAN
R2(config-sec-zone-pair)#description LAN-TO-WAN TRAFFIC

R2(config)#zone-pair security WAN-TO-LAN source WAN destination LAN
R2(config-sec-zone-pair)#description WAN-TO-LAN TRAFFIC

Above I create two zone pairs. One for traffic from our LAN to the WAN, and another for traffic from the WAN to our LAN. A description is optional but recommended if you have many zones. Let’s verify our configuration:

R2#show zone-pair security 
Zone-pair name LAN-TO-WAN
Description: LAN-TO-WAN TRAFFIC
    Source-Zone LAN  Destination-Zone WAN 
    service-policy not configured
Zone-pair name WAN-TO-LAN
Description: WAN-TO-LAN TRAFFIC
    Source-Zone WAN  Destination-Zone LAN 
    service-policy not configured

Now we have zones, zone pairs and interfaces that are assigned to the zones. By default all traffic will be blocked. Let’s see if this is true:

R1#ping 192.168.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

As you can see I’m unable to ping from one zone to another by default. Our next step is to implement some security policies to decide what we are allowed to do or not.

Security Policies

Security policies are similar to policy-maps for QoS with the MQC where we use class-maps to select traffic. There are three actions that we can apply to traffic:

• Pass: traffic is permitted.
• Drop: traffic is dropped.
• Inspect: traffic is permitted and inspected so that return traffic is allowed.

We’ll start with a simple security policy that allows ICMP traffic from the LAN to the WAN:

R2(config)#class-map type inspect ICMP
R2(config-cmap)#match protocol icmp

R2(config)#policy-map type inspect LAN-TO-WAN
R2(config-pmap)#class type inspect ICMP
R2(config-pmap-c)#inspect

I will create an inspect class-map that uses NBAR to match ICMP traffic and a policy-map called LAN-TO-WAN to assign an action to the class-map. I will use inspect as it will allow the traffic to pass from the LAN zone to the WAN zone but also allows the return traffic. Now we can apply the policy-map to the zone pair:

R2(config)#zone-pair security LAN-TO-WAN
R2(config-sec-zone-pair)#service-policy type inspect LAN-TO-WAN

Policy-maps are directly attached to the zone pair that we created earlier. Let’s verify that our configuration is working:

R1#ping 192.168.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

As you can see our ping from R1 to R3 is now successful. What about the other way around?

R3#ping 192.168.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

ICMP traffic from R3 to R1 is now allowed as expected. To check the current active security policies you can use the following command:

R2#show policy-map type inspect zone-pair 
 Zone-pair: LAN-TO-WAN

  Service-policy inspect : LAN-TO-WAN

    Class-map: ICMP (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:30]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [1:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:0]
        Last session created 00:00:05
        Last statistic reset never
        Last session creation rate 1
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        4 packets, 96 bytes

Above you can see that ICMP traffic is allowed from the LAN zone to the WAN zone while all other traffic (class-default) will be dropped.

Let’s create another rule, let’s say that R3 is allowed to telnet to R1. We’ll create a new class-map, policy-map and attach it to the correct zone-pair:

R2(config)#class-map type inspect TELNET
R2(config-cmap)#match protocol telnet

R2(config)#policy-map type inspect WAN-TO-LAN
R2(config-pmap)#class type inspect TELNET
R2(config-pmap-c)#inspect

R2(config)#zone-pair security WAN-TO-LAN
R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-LAN

Let’s verify our configuration:

R3#telnet 192.168.12.1
Trying 192.168.12.1 ... Open

As you can see above we are now able to telnet from R3 to R1.

R2#show policy-map type inspect zone-pair | begin WAN-TO-LAN
 Zone-pair: WAN-TO-LAN

  Service-policy inspect : WAN-TO-LAN

    Class-map: TELNET (match-all)
      Match: protocol telnet
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [0:20]

        Session creations since subsystem startup or last reset 1
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:1]
        Last session created 00:01:11
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

As you can see telnet traffic is allowed, all other traffic will be dropped.

Zone Self

With the configuration above we have security rules between the LAN and WAN zones, but what about R2 itself? Is it protected by our zone based firewall? Let’s find out!

R3#telnet 192.168.23.2
Trying 192.168.23.2 ... Open

R3 is able to telnet to R2 without any problems. This is because R2 doesn’t belong to the WAN or LAN zone but to another zone called the self zone. By default all zones are allowed to reach the self zone, so if we don’t want this we’ll have to create another zone pair:

R2(config)#policy-map type inspect WAN-TO-SELF

I will create a policy-map called WAN-TO-SELF but I won’t use any class-maps. By default there is always the class-default and it will drop all traffic. Let’s create the zone pair:

R2(config)#zone-pair security WAN-TO-SELF source WAN destination self
R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-SELF

Let’s verify our work:

R3#ping 192.168.23.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show policy-map type inspect zone-pair WAN-TO-SELF
 Zone-pair: WAN-TO-SELF

  Service-policy inspect : WAN-TO-SELF

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        15 packets, 360 bytes

Above you can see the drops in the class-default. This will prevent the WAN zone from sending traffic to the self zone. The LAN zone will still be able to reach R2.

hostname R1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2
!
end

hostname R2
!
ip cef
!
class-map type inspect match-all TELNET
 match protocol telnet
class-map type inspect match-all ICMP
 match protocol icmp
!
policy-map type inspect LAN-TO-WAN
 class type inspect ICMP
  inspect
 class class-default
  drop
policy-map type inspect WAN-TO-LAN
 class type inspect TELNET
  inspect
 class class-default
  drop
policy-map type inspect WAN-TO-SELF
 class class-default
  drop
!
zone security LAN
zone security WAN
zone-pair security LAN-TO-WAN source LAN destination WAN
 description LAN-TO-WAN TRAFFIC
 service-policy type inspect LAN-TO-WAN
zone-pair security WAN-TO-LAN source WAN destination LAN
 description WAN-TO-LAN TRAFFIC
 service-policy type inspect WAN-TO-LAN
zone-pair security WAN-TO-SELF source WAN destination self
 service-policy type inspect WAN-TO-SELF
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 zone-member security LAN
!
interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
 zone-member security WAN
!
end

hostname R3
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.23.2
!
end

I hope this example has helped you to understand zone based firewalls, if you have any questions feel free to ask!

Transparent Cisco IOS Firewall

Cisco IOS routers can be configured as a layer 2 bridges, this means that you can configure two or more interfaces to be in the same layer 2 domain and that traffic will be switched instead of routed. Another feature that has been added since IOS 12.3(7)T is the transparent Cisco IOS Firewall. This allows traffic filtering and stateful inspection using CBAC for the layer 2 bridge.

When you configure the router as a transparent firewall it will not do any routing and will only learn the MAC addresses on the interfaces and switch frames between the interfaces. The advantage of a transparent firewall is that you can place it at any location in your network without having to change any IP addresses or networking settings like default gateways.

To demonstrate this feature I will use the following topology:

Above we have a small network with 3 routers…R1,R2 and R3. R2 will be configured to bridge its Fastethernet 0/0 and 0/1 interfaces together. This means that R1 and R3 will be in the same layer 2 domain.

R1 and R3 will use IPv4 subnet 192.168.13.0 /24 and IPv6 prefix 2001:13::/64. I will configure the firewall with the following requirements:

• R1 should be able to reach R3 using TCP, UDP and ICMP.
• R3 is not allowed to send anything to R1 with the exception of return traffic.
• IPv6 traffic between R1 and R3 is not allowed.

Let’s take a look how to achieve this!

Configuration

First we will configure R2 as a bridge. You have two options here:

• CRB (Concurrent Routing and Bridging)
• IRB (Integrated Routing and Bridging)

When you use CRB the router will act as a layer 2 bridge for all interfaces that are in the bridge group and all other interfaces will be layer 3.

With IRB you will be able to configure a BVI (Bridge Virtual Interface) for each bridge group. This is a layer 3 interface for the bridge group and you can compare it to the SVI (Switch Virtual Interface) on Catalyst switches. I’m not going to use any layer 3 services on R2 so I’ll choose CRB:

R2(config)#bridge crb

Bridging is now enabled. Let’s activate spanning-tree:

R2(config)#bridge 1 protocol ieee

This will make the router run the IEEE version of spanning-tree. Let’s continue and add the two interfaces of R2 to the bridge group:

R2(config)#interface fastEthernet 0/0
R2(config-if)#bridge-group 1

R2(config)#interface fastEthernet 0/1
R2(config-if)#bridge-group 1

This finishes our bridge configuration so we can continue with our transparent firewall configuration. First I’ll create an access-list that blocks all IP traffic:

R2(config)#ip access-list extended R3-TO-R1
R2(config-ext-nacl)#deny ip any any

We’ll activate the access-list inbound on the link between R2 and R3:

R2(config)#interface fastEthernet 0/1
R2(config-if)#ip access-group R3-TO-R1 in

To make sure that R1 can reach R3 I’ll create some CBAC inspect rules:

R2(config)#ip inspect name CBAC tcp
R2(config)#ip inspect name CBAC udp
R2(config)#ip inspect name CBAC icmp

This should allow all TCP, UDP and ICMP traffic from R1 to R3. Let’s activate it inbound on the interface pointing to R1:

R2(config)#interface fastEthernet 0/0
R2(config-if)#ip inspect CBAC in

Besides access-lists for IP and inspect rules I can also use protocol access-lists. This will help us to block IPv6 traffic:

R2(config)#access-list 200 deny 0x86DD
R2(config)#access-list 200 permit 0x0 0xFFFF

We’ll deny EtherType 086DD (IPv6) and permit all other EtherTypes. Let’s apply this protocol access-list to the bridge group:

R2(config)#interface fastEthernet 0/0
R2(config-if)#bridge-group 1 input-type-list 200

R2(config)#interface fastEthernet 0/1        
R2(config-if)#bridge-group 1 input-type-list 200

With the configuration above, R1 should be able to reach R3 using TCP, UDP or ICMP and IPv6 traffic should be blocked. Let’s find out if our configuration is working!

Verification

The first thing you should do is check if your bridge is operational and learning MAC addresses:

R2#show bridge 

Total of 300 station blocks, 298 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address       Action   Interface       Age   RX count   TX count
c200.23f6.0000   forward   FastEthernet0/0   2         10         10
c202.23f6.0000   forward   FastEthernet0/1   2         11          9

R2 has learned the MAC addresses of R1 and R3. Let’s check our CBAC inspect rules:

R2#show ip inspect config 
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [unlimited : unlimited] connections
max-incomplete sessions thresholds are [unlimited : unlimited]
max-incomplete tcp connections per host is unlimited. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name CBAC
    tcp alert is on audit-trail is off timeout 3600
    udp alert is on audit-trail is off timeout 30
    icmp alert is on audit-trail is off timeout 10

Above we can see that TCP, UDP and ICMP will be inspected. Let’s send some traffic from R3 to R1 to see if our firewall works:

R3#ping 192.168.13.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show access-lists R3-TO-R1
Extended IP access list R3-TO-R1
    10 deny ip any any (5 matches)

We see matches in the access-list as R3 is hitting the ‘deny ip any any’. Let’s see if R1 can reach R3:

R1#ping 192.168.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

R2#show ip inspect sessions    
Established Sessions
 Session 66E555E8 (192.168.13.1:8)=>(192.168.13.3:0) icmp SIS_OPEN

That’s looking better, thanks to our inspect rules R1 can reach R3. What about IPv6? Will it be filtered?

R1#ping 2001:13::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:13::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show access-lists 200
Type code access list 200
    deny   0x86DD 0x0000 (28 matches)
    permit 0x0000 0xFFFF (67 matches)

As you can see IPv6 traffic is being blocked thanks to the protocol access-list. That’s all there is to it!

hostname R1
!
ip cef
!
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/0
 ip address 192.168.13.1 255.255.255.0
 ipv6 address 2001:13::1/64
 ipv6 enable
!
end

hostname R2
!
ip cef
!
ip inspect name CBAC tcp
ip inspect name CBAC udp
ip inspect name CBAC icmp
!
bridge crb
!
interface FastEthernet0/0
 no ip address
 ip inspect CBAC in
 bridge-group 1
 bridge-group 1 input-type-list 200
!
interface FastEthernet0/1
 no ip address
 ip access-group R3-TO-R1 in
 bridge-group 1
 bridge-group 1 input-type-list 200
!
ip access-list extended R3-TO-R1
 deny   ip any any
!
access-list 200 deny   0x86DD 0x0000
access-list 200 permit 0x0000 0xFFFF
!
bridge 1 protocol ieee
!
end

hostname R3
!
ip cef
!
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/0
 ip address 192.168.13.3 255.255.255.0
 ipv6 address 2001:13::3/64
 ipv6 enable
!
end

I hope this example helps you to understand the Transparent Cisco IOS Firewall. If you have any questions feel free to leave a comment!