Transparent Cisco IOS Firewall

Cisco IOS routers can be configured as layer two bridges, this means that you can configure two or more interfaces to be in the same layer two 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 two bridge.

Configuring the router as a transparent firewall will not do any routing and will only learn the MAC addresses on the interfaces and switch frames between them. 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:

IOS transparent firewall demo 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 R1 and R3 will be in the same layer two domain.

R1 and R3 will use IPv4 subnet /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 except return traffic.
  • IPv6 traffic between R1 and R3 is not allowed.

Let’s take a look at how to achieve this!


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 two bridge for all interfaces in the bridge group, and all other interfaces will be layer 3.

With IRB, you can configure a BVI (Bridge Virtual Interface) for each bridge group. This is a layer three 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 three 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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 785 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1832 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,

Forum Replies

  1. Hi all, I labbed up transparent bridging. R1 is able to ping R3 etc and everything seems to be working, however, when i apply the access-list to the interface fa 0/1 of R2, it seems like it never gets a hit. Traffic continues to flow, there’s no dropping of traffic. any idea why???

  2. so from what i can tell, when the traffic comes back from R3, R2 only looks at the layer 2 information. Since R2 knows the frame is destined for the mac address it switches the frame at layer2. In other words, the ACL is never checked. So how rene did this lab is a mystery to me…
    I’m doing the lab in gns3 using Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(25)

  3. Hello Kam

    Pinging from R1 to R3 will work whether you have the access list applied to Fa0/1 or not, as the access list will allow traffic from R1 to R3 as well as responding traffic. Try pinging from R3 to R1 to see if the access list is blocking.

    Now it is true that the access list is applied to a layer 2 interface, however, access lists that are configured to inspect tcp, udp and icmp as is the case here will also check higher level protocols to determine if a frame can be forwarded or should be dropped.

    Let us know of your results and if need be, we can hel

    ... Continue reading in our forum

  4. Hi Lagapides

    According wording “This means that R1 and R3 will be in the same layer 2 domain.” , it mean if Braodcast strom happen from R1 then it effect with R3 right ?
    If Yes, How we limited Broadcast storm ?.

  5. Hello Vittawat

    Yes that is correct. In the specific topology, R2 would essentially function as a switch so any broadcasts sent on Fa0/0 of R1 would reach the Fa0/0 interface of R3.

    Now as for your question about limiting broadcast storms, for a topology similar to that in the lesson, a broadcast storm w

    ... Continue reading in our forum

6 more replies! Ask a question or join the discussion by visiting our Community Forum