Cisco IOS Transparent Firewall

Most students or regular users of the Cisco ASA security appliance are at least aware of the fact that the device can optionally be provisioned as a Layer 2 (or transparent firewall). What is less known, however, is that this same functionality is available on the Cisco IOS® router. This article will briefly explore how transparent firewall is configured on the router and how this implementation differs from that on the ASA.

The first fundamental difference which must be considered between the two platforms is that the Cisco IOS router does not support security levels. As a result, we don’t have the implicit “deny all” behavior for packets coming from less secure security zones or networks into more secure ones. A router, by contrast, has an implicit “permit all” behavior; consequently, access-lists must be explicitly configured to deny all traffic coming through interfaces deemed to be less secure.

One strong similarity between the two platforms is that only IP packets are subject to the firewall inspection; non-IP packets (such as IPX, Appletalk, etc.) have to be controlled using EtherType access lists, which, on the IOS router are configured using the number range 200-299. Consistent with what was mentioned above, the router will implicitly permit all bridged non-IP traffic whereas the ASA will deny it.

A big advantage for the router is its ability to perform Integrated Routing and Bridging by the use of Bridged Virtual Interfaces (BVI). The ASA is currently restricted to an either router or transparent mode with only two interfaces permitted for each virtual transparent firewall (a.k.a. security context.). Besides the fact that the router is not subject to the two-interface restriction, it can also be configured with interfaces which are trunked. To visualize a sample implementation, consider the topology below:

In this implementation, the Cisco IOS transparent firewall is providing additional screening between the Demilitarized Zone (DMZ) interface of the firewall and the servers. Typically in a scenario such as this one, the servers should not initiate connections; consequently, we will deny all packets coming into the FastEthernet0/1 interface unless they represent responses to externally initiated sessions. For this example (not a typical concern these days!) we will deny IPX traffic from passing in the event a server was misconfigured. A sample configuration is provided below:

Router(config)# ! Specify bridging params (Spanning-Tree here)
Router(config)# bridge 1 protocol ieee
Router(config)# !
Router(config)# ! Define an Ethertype ACL to permit IP & deny IPX
Router(config)# access-list 200 permit 0x0800
Router(config)# access-list 200 deny 0x8137
Router(config)# !
Router(config)# ! IP ACL to prevent DMZ initiated connections
Router(config)# access-list 100 deny ip any any
Router(config)# !
Router(config)# ! Generic TCP inspection rule
Router(config)# ip inspect name To-DMZ tcp
Router(config)# !
Router(config)# ! Apply the inspection rule, ACLs, bridging
Router(config)# interface FastEthernet0/0
Router(config-if)# ip inspect To-DMZ in
Router(config-if)# bridge-group 1
Router(config)# interface FastEthernet0/1
Router(config-if)# bridge-group 1
Router(config-if)# bridge-group 1 input-type-list 200
Router(config-if)# ip access-group 100 in

The sample configuration above is minimal at best and would often be supplemented by adding additional inspections, additional EtherType ACL entries, and possibly the Integrated Routing and Bridging (IRB) functionality.

Two more features worthy of note to conclude this article:

  1. DHCP pass-through: Provision has been made for DHCP requests to be capable of bypassing inspection by the use of
    Router(config) # ip inspect L2-transparent  dhcp-passthrough
  2. debug capability: detailed troubleshooting assistance can be provided  with a characteristic L2FW: marker via
    debug ip inspect L2-transparent {packet | dhcp-passthrough}

References:

In this article

Join the Conversation