Introduction
This short application note intends to clarify the operation of the Firewall Service Module (FWSM) virtual firewall’s packet classifier. The reader should have a basic understanding of the virtual firewall feature set.
Using FWSM’s virtual firewall functionality, it is possible to share interfaces between a set of security contexts as illustrated in the following picture:
Figure 1: VLAN sharing
Figure 1 represents 3 security contexts all sharing a common VLAN (500) – a single IP subnet corresponds to that VLAN. This is equivalent to connecting three security appliances using an Ethernet switch. A property of the FWSM makes all interfaces across the entire module use only one global MAC address (‘M’ in Figure 1). This is usually not a problem, until multiple contexts start sharing an interface. Indeed, under normal circumstances each device on a shared media uses a distinct MAC address. A router would find it quite challenging to direct packets to x.x.x.2, x.x.x.3 or x.x.x.4 considered all three IP addresses resolve to the same MAC address M. Also, the bridging table of the switch would constantly change as MAC address M moves from one port to another. These are definitely not ideal conditions. The purpose of the virtual firewall’s classifier is to resolve this situation.
How the classifier operates
From a logical point of view, this is how the FWSM interprets Figure 1:
Figure 2: VFW Classifier
The purpose of the classifier is to determine what context to send a packet to when that packet arrives on a shared interface. Such a mechanism is necessary because of the MAC address ambiguity among other things. Suppose the MSFC sends out a packet destined to 10.20.10.50. Here is a snapshot of the MSFC’s routing table:
MSFC#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS ia
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
192.168.1.0/24 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Vlan500
S 10.10.10.0/24 [1/0] via 192.168.1.2
S 10.20.10.0/24 [1/0] via 192.168.1.3
S 10.30.10.0/24 [1/0] via 192.168.1.4
The MSFC must now resolve next-hop 192.168.1.3. It soon determines its MAC address is M, and proceeds to send a packet to {Dest IP=10.20.10.50; Dest MAC=M}. The problem is that M is owned by all three contexts, which one does the packet really belong to? The classifier intercepts the packet and performs a destination IP address lookup. All other fields are ignored, only the destination IP address matters. This of course supposes the classifier has some knowledge about the subnets located behind each security context. Surprisingly enough, it doesn’t! The classifier does not have visibility into each context’s routing table. It solely relies on static statements entered within each context, or on translation slots (referred to as xlates) created by traffic originating from these contexts. In other words, the only way for the classifier to gain knowledge about subnets 10.10.10.0, 10.20.10.0 and 10.30.10.0 is if the contexts’ administrators configure statements such as these into each context:
Context-A:
static(inside, shared) 10.10.10.0 10.10.10.0 netmask 255.255.255.0
Context-B:
static(inside, shared) 10.20.10.0 10.20.10.0 netmask 255.255.255.0
Context-C
static(inside, shared) 10.30.10.0 10.30.10.0 netmask 255.255.255.0
This configuration transforms Figure 2 into:
Figure 3: contexts inject their statics in the classifier
An alternate way for the classifier to build its routing table is by relying on xlates that exist within each context. A xlate is dynamically created when a packet from a high security level interface initiates an outbound connection to a lower security level interface. In our example, if a host on 10.XX.10.0 sends a packet out via the shared interface, a xlate is created – revealing the real or NAT’d source IP address of the inside host. This is illustrated below:
Figure 4: xlate creation
Without any static statement configured on the firewall, outside traffic that attempts to communicate with inside host 10.20.10.100 is dropped by the firewall. However, when that same inside host sends out a packet to a destination off the shared interface an xlate is created. A xlate allows return traffic to hit back the inside host. The classifier learns about those xlates and is able to properly send outside traffic to the right context. The drawback to this is that communication to an inside subnet is only possible if a host on that subnet has previously originated traffic.
Starting with FWSM release 2.3(2.17) – meaning 2.3(3) and 3.1(1) – a new command has been implemented to gather information about static() entries across all contexts. This makes it easier to quickly identify possible overlaps between different contexts, a situation that leads to connectivity problems. The new command is simply show np 3 static executed from the system context.
An interesting side effect
Because the classifier bases its packet-forwarding decisions on static() statements, there are cases where those statements are actually preferred over static routes! Consider the topology represented in Figure 5:
Figure 5: static() preferred over static route
Figure 5 shows a configuration where two virtual firewalls share their outside interface. Subnet 100.x.x.x is off the inside of Context 1 while 200.x.x.x is off the inside of Context 2. There is a static route in Context 1 pointing to the MSFC as the next-hop to reach 200.x.x.x. There is also a static(inside,outside) statement in Context 2 claiming ownership for the 200.x.x.x subnet.
When a packet destined to 200.x.x.x enters Context 1 via the inside interface, one would expect Context 1 to send that packet to the MSFC according to the static route. That is actually not what is happening. The classifier prefers the static statement and internally routes the packet from Context 1 to Context 2, despite the static route.
NAT zero access-list and shared interfaces
On the FWSM and the PIX Firewall, there is a technique called “NAT zero access-list” that allows an administrator to allow low-security level to higher security level communication without using any static statements or NAT translation. This does not work in a shared interface environment because NAT(zero)ACL prevents the classifier from learning the inside subnets (10.10.10.0 and 10.20.10.0 in Figure 6):
Figure 6: NAT zero ACL incompatibility
Hosts on shared interfaces can’t initiate outbound connections
Another side effect of the classifier, or rather the ubiquity of a single MAC address per FWSM, is the fact that hosts on shared interfaces can’t initiate outbound connections. Consider the following figure:
Figure 7: host can’t initiate outbound connections
Suppose the PC wishes to connect to a device located beyond the two security contexts. It could have a static default route pointing 10.10.10.1. The PC first sends an ARP request for 10.10.10.1, which is answered by the FWSM. Next, the PC attempts to contact the remote device – the destination MAC address in the Ethernet frame is that of the FWSM. The classifier intercepts the packet as both contexts share the same MAC address, and tries to determine what context the packet is destined to. The lookup fails unless a static statement exist for the destination address, which is highly unlikely if the destination is somewhere on the Internet.
Cascading contexts: what is possible and what is not
The classifier also imposes a (software-based) restriction on the number of contexts that can be cascaded. This limit is set to 2 contexts in release 2.2(1). Topologies such as the one depicted by Figure 8 are therefore not supported:
Figure 8: cascading more than 2 contexts is not allowed
When a packet leaves Context A to enter Context B, it goes through a classifier round – indeed, there is a shared interface between Contexts A and B – just as if it came from the outside of the FWSM. The classifier won’t allow a packet to circulate through the classifier more than once. No particular error message is displayed when the packet is dropped as it attempts to recirculate through the classifier. On the other hand, the following topology is supported:
Figure 9: cascading two contexts is possible
A static route must be installed in Context A to point to B as a next-hop to 10.20.10.0/24, and vice versa.
The following configurations should be avoided:
Figure 10: topologies to avoid
Sharing the inside interface is not recommendable, partly because it is very cumbersome to define outside NAT statements for all destinations located beyond each context.
An alternative to shared interfaces
Because of the fairly complex caveats associated with sharing interfaces on the FWSM, it is recommended to use the MSFC (the routing engine of the Catalyst 6500/7600 switches) as an aggregation point between various contexts rather than having them share interfaces. Here is an example that shows how to transform a shared interface topology into one where the MSFC is used as a hub router:
Figure 11: MSFC as an inter-context router
The topology represented in Figure 11 is possible when using a global configuration mode parameter on the MSFC that permits the creation of several (unlimited) links between the MSFC and the FWSM. By default, at most one VLAN can exist between the MSFC and the FWSM. To override this setting, use the firewall multiple-vlan-interfaces command on the router.
Hope this document is informative and I want to thank you for viewing.
