A VRF-aware firewall inspects IP packets that are sent or received within a VRF. VRF allows multiple instances of routing tables to coexist within a single router. This allows VPN segregation and the ability to have independent overlapping of IP address spaces. VRF allows traffic from the customers of one service provider to be isolated from another. The Cisco IOS XE VRF support splits the router into multiple routing domains, with each routing domain consisting of its own set of interfaces and routing and forwarding tables. Each routing domain is referenced by a unique identifier called the table ID. The global routing domain and the default routing domain (that is not associated with any VRF) is addressed with the table ID, zero. VRF supports overlapping of IP address space, thereby allowing the traffic from nonintersecting VRFs to have the same IP address.

The VRF-Aware Cisco IOS XE Firewall provides the following benefits:

• Scalable deployment—Scales to meet any network’s bandwidth and performance requirements.

• VPN support—Provides a complete VPN solution based on Cisco IOS XE IPsec and other software-based technologies, including Layer 2 Tunneling Protocol (L2TP) tunneling, and quality of service (QoS).

• AIC support—Provides policy maps for the Internet Message Access Protocol (IMAP), Post Office Protocol 3 (POP3), Simple Mail Transfer Protocol (SMTP), and Sun Remote Procedure Call (SUN RPC)

• Allows users to configure a per-VRF firewall. The firewall inspects IP packets that are sent and received within a VRF. The firewall also inspects traffic between two different VRFs (intersecting VRFs).

• Allows SPs to deploy the firewall on the provider edge (PE) router.

• Supports overlapping IP address space, thereby allowing traffic from nonintersecting VRFs to have the same IP address.

• Supports VRF (not global) firewall command parameters and Denial-of-Service (DoS) parameters so that the VRF-aware firewall can run as multiple instances (with VRF instances) that are allocated to various VPN customers.

• Generates high-speed logging (HSL) messages that contain the VRF ID; however these messages are collected by a single collector.

The VRF-aware firewall allows you to limit the number of firewall sessions. If the firewall sessions are not limited, it would be difficult for VRFs to share router resources because one VRF may consume a maximum amount of resources, leaving few resources for other VRFs and thereby causing the denial of service to other VRFs.

Note	On the Cisco ASR 1000 Series Aggregation Services Routers the firewall supports a maximum of 4000 VRFs.

A VRF splits the device into multiple routing domains. Each of these routing domains contain their own set of interfaces and routing tables. A routing table is referenced by using a per-VRF unique table ID. Zero is the default global routing table ID that is not associated with a VPN routing and forwarding (VRF).

Nonintersecting VRFs are allowed to have overlapping address spaces (that is, the IP address of one VRF may be contained in others).

VPN routing and forwarding (VRF) allows multiple instances of routing tables to coexit within a single device. A VRF contains a template of a VRF table in a provider edge (PE) device.

The overlapping addresses, usually resulting from the use of private IP addresses in customer networks, are one of the major obstacles to the successful deployment of a peer-to-peer (P2P) VPN implementation. You can use the Multiprotocol Label Switching (MPLS) VPN technology to overcome the overlapping addresses issue.

Each VPN has its own routing and forwarding table in the device so that any customer or site that belongs to a VPN is provided access only to the set of routes contained within that table. Any PE device in the MPLS VPN network therefore contains a number of per-VPN routing tables and a global routing table that is used to reach other devices in the service provider (SP) network. Effectively, a number of virtual devices are created in a single physical device.

The VRF-Lite Aware Firewall feature, also called the VRF without MPLS-aware firewall, allows a firewall zone to be applied to non-MPLS-enabled VPN routing and forwarding (VRF) interfaces.

The VRF-Lite Aware Firewall feature enables a service provider (SP) to support two or more VPNs, in which IP addresses can be overlapped among VPNs. VRF-lite uses input interfaces to distinguish routes for different VPNs and forms virtual packet forwarding tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be physical, such as Ethernet ports, or logical, such as VLAN switched virtual interfaces (SVIs). However, a Layer 3 interface cannot belong to more than one VRF at a time.

Note	All VRF-lite interfaces must be Layer 3 interfaces.

VRF-lite includes the following devices:

• Customer edge (CE) devices provide customers access to the SP network over a data link. The CE device advertises the site’s local routes to the provider edge (PE) device and learns about the remote VPN routes from the PE device.

• PE devices exchange routing information with CE devices by using static routing or a routing protocol such as Border Gateway Protocol (BGP), Routing Information Protocol Version 1 (RIPv1), or RIPv2.

• PE devices (or core devices) are any devices in the SP network that are not attached to CE devices.

• A PE device is only required to maintain VPN routes for those VPNs to which it is directly attached, eliminating the need for the PE device to maintain all the SP VPN routes. Each PE device maintains a VRF for each of its directly connected sites. Multiple interfaces on a PE device can be associated with a single VRF, if all of these sites are part of the same VPN. Each VPN is mapped to a specified VRF. After learning local VPN routes from CE devices, a PE device exchanges VPN routing information with other PE devices by using internal BGP (iBPG).

With VRF-lite, multiple customers can share one CE device, and only one physical link is used between the CE device and the PE device. The shared CE device maintains a separate VRF table for each customer, and switches or routes packets for each customer based on its own routing table. VRF-lite extends the limited PE device functionality to a CE device, giving it the ability to maintain separate VRF tables to extend the privacy and security of a VPN to the branch office.

Figure 1. Firewall in a VRF-to-VRF Scenario

The Multiprotocol Label Switching (MPLS) VPN Feature allows multiple sites to interconnect transparently through a service provider (SP)network. One SP network can support several IP VPNs. Each VPN appears to its users as a private network, separate from all other networks. Within a VPN, each site can send IP packets to any other site in the same VPN.

Each VPN is associated with one or more VPN routing and forwarding (VRF) instances. A VRF consists of an IP routing table, a derived Cisco Express Forwarding table, and a set of interfaces that use the forwarding table.

The device maintains a separate routing and Cisco Express Forwarding table for each VRF. This prevents information from being sent outside the VPN and allows the same subnet to be used in several VPNs without causing duplicate IP address problems.

The device using Multiprotocol BGP (MP-BGP) distributes the VPN routing information using the MP-BGP extended communities.

Network Address Translation (NAT) allows a single device, such as a device, to act as an agent between the Internet (or public network) and a local (or private) network. Although NAT systems can provide broad levels of security advantages, their main objective is to economize on address space.

NAT allows organizations to resolve the problem of IP address depletion when they have existing networks and need to access the Internet. Sites that do not possess Network Information Center (NIC)-registered IP addresses must acquire them. NAT eliminates the concern of NIC-registered IP addresses by dynamically mapping thousands of hidden internal addresses to a range of easy-to-get addresses.

A NAT system makes it difficult for an attacker to determine the following:

• Number of systems running on a network.

• Type of machines and operating systems running on the network.

• Network topology and arrangement.

NAT integration with Multiprotocol Label Switching (MPLS) VPNs allows multiple MPLS VPNs to be configured on a single device to work together. NAT can differentiate the MPLS VPNs from which it receives the IP traffic, even if all MPLS VPNs use the same IP addressing scheme. This enables multiple MPLS VPN customers to share services while ensuring that each MPLS VPN is completely separate from the other.

To provide value-added services, such as, Internet connectivity, domain name servers (DNS), and VoIP service to customers, MPLS service providers must use NAT. NAT helps MPLS VPN customers to use overlapped IP addresses in their network.

NAT can be implemented on a customer edge (CE) device or on a provider edge (PE) device. The NAT integration with MPLS VPNs feature enables the implementation of NAT on a PE device in an MPLS cloud.

An application-layer gateway (ALG) is an application that translates the IP address information inside the payload of an application packet. The ALGs identify the address information in the packet payload that needs to be overwritten by NAT and supply the address information to NAT and firewall to create subordinate flows or doors to allow data to flow properly (an example of data flow is FTP data flow. Doors are transient structures that allow incoming traffic that matches a specific criterion. A door is created when there is not enough information to create a complete NAT session entry. A door contains information about the source and destination IP address and the destination port. However, it does not have information about the source port. When media data arrives, the source port information is known and the door is promoted to a real NAT session.

The VRF-Aware IPsec feature maps an IPsec tunnel to a Multiprotocol Label Switching (MPLS) VPN. Using the VRF-Aware IPsec feature, you can map IPsec tunnels to VPN routing and forwarding (VRF) instances using a single public-facing IP address.

Each IPsec tunnel is associated with two VRF domains. The outer encapsulated packet belongs to a VRF domain called the Front Door VRF (FVRF). The inner, protected IP packet belongs to a domain called the Inside VRF (IVRF). In other words, the local endpoint of the IPsec tunnel belongs to the FVRF, whereas source and destination addresses of the inside packet belong to the IVRF.

One or more IPsec tunnels can terminate on a single interface. The FVRF of all these tunnels is the same and is set to the VRF that is configured on that interface. The IVRF of these tunnels can be different and depends on the VRF that is defined in the Internet Security Association and Key Management Protocol (ISAKMP) profile that is attached to a crypto map entry.

The following figure illustrates a scenario showing IPsec to MPLS and Layer 2 VPNs.

Figure 2. IPsec-to-MPLS and Layer 2 VPNs

The VRF-Aware Software Infrastructure (VASI) allows you to apply services such as access control lists (ACLs), NAT, policing, and zone-based firewalls to traffic that is flowing across two different VRF instances. The VASI interfaces support redundancy of the Route Processor (RP) and Forwarding Processor (FP). This feature supports IPv4 and IPv6 unicast traffic on VASI interfaces.

The primary use of VASI is to allow better isolation of VRFs. The VASI allows for per-VRF-specific features to be applied to the VASI interface without any impact to other VRFs that may share a common interface (for example, all VRFs may share the same interface to the Internet). For the firewall, this feature allows zones to be applied to the VASI.

VASI is implemented by using virtual interface pairs, where each of the interfaces in the pair is associated with a different VRF. The VASI virtual interface is the next hop interface for any packet that needs to be switched between these two VRFs. VASI interfaces provide the framework necessary to support NAT between two VRFs.

Each interface pair is associated with two different VRF instances. The two virtual interfaces, called vasileft and vasiright, in a pair are logically wired back-to-back and are completely symmetrical. Each interface has an index. The association of the pairing is done automatically based on the two interface indexes such that vasileft automatically gets paired to vasiright. You can configure either static routing or dynamic routing with BGP, Enhanced Interior Gateway Routing Protocol (EIGRP), or Open Shortest Path First (OSPF). BGP dynamic routing protocol restrictions and configuration are valid for BGP routing configurations between VASI interfaces. For more information on VASI, see the “Configuring the VRF-Aware Software Infrastructure” feature.

A security zone is a group of interfaces to which a policy can be applied.

Grouping interfaces into zones involves two procedures:

• Creating a zone so that interfaces can be attached to it.

• Configuring an interface to be a member of a given zone.

By default, traffic flows among interfaces that are members of the same zone.

When an interface is a member of a security zone, all traffic (except traffic going to the device or initiated by the device) between that interface and an interface within a different zone is dropped by default. To permit traffic to and from a zone-member interface and another interface, you must make that zone part of a zone pair and apply a policy to that zone pair. If the policy permits traffic through inspect or pass actions, traffic can flow through the interface.

The following are basic rules to consider when setting up zones:

• Traffic from a zone interface to a nonzone interface or from a nonzone interface to a zone interface is always dropped; unless default zones are enabled (default zone is a nonzone interface).

• Traffic between two zone interfaces is inspected if there is a zone pair relationship for each zone and if there is a configured policy for that zone pair.

• By default, all traffic between two interfaces in the same zone is always allowed.

• A zone pair can be configured with a zone as both source and destination zones. An inspect policy can be configured on this zone pair to inspect or drop the traffic between two interfaces in the same zone.

• An interface can be a member of only one security zone.

• When an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.

• Traffic cannot flow between an interface that is a member of a security zone and an interface that is not a member of a security zone because a policy can be applied only between two zones.

• For traffic to flow among all interfaces in a device, these interfaces must be members of one security zone or another. It is not necessary for all device interfaces to be members of security zones.

The figure below illustrates the following:

• Interfaces E0 and E1 are members of security zone Z1.

• Interface E2 is a member of security zone Z2.

• Interface E3 is not a member of any security zone.

Figure 3. Security Zone Restrictions

The following situations exist:

• The zone pair and policy are configured in the same zone. Traffic flows freely between interfaces E0 and E1 because they are members of the same security zone (Z1).

• If no policies are configured, traffic will not flow between any other interfaces (for example, E0 and E2, E1 and E2, E3 and E1, and E3 and E2).

• Traffic can flow between E0 or E1 and E2 only when an explicit policy permitting traffic is configured between zone Z1 and zone Z2.

• Traffic can never flow between E3 and E0/E1/E2 unless default zones are enabled.

Note	On the Cisco ASR 1000 Series Aggregation Services Routers the firewall supports a maximum of 4000 zones.

A firewall can be deployed at many points within the network to protect VPN sites from shared service (or the Internet) and vice versa. This section describes the following firewall deployment scenarios: