Chapter 4. IOS IPsec Implementation
The following chapter reviews the modes of encapsulation used within IPsec by describing tunnel and transport modes and how these are used. If you have not read chapter 1, “Introduction to IPsec VPNs,”—which describes tunnel and transport mode, it may be prudent to do so before starting this chapter.
Before tunnel interfaces are described, crypto map should be discussed. A crypto map is a Cisco IOS software configuration attribute that performs a number of functions related to setting up an IPsec Security Association. Within a crypto map, data flows are defined that are to be protected by the SA and require security processing or traffic that is required to be bypassed; these are referenced with an access control list. The way that the traffic will be protected (which security policy, protocol, mode, and algorithms) is defined by the IPsec transform-set, and to whom the session will be established is defined by the peer statement. These attributes can be aligned to the Security Policy Database (SPD).
A crypto map is applied to an interface, which then enables the SPD instance; this results in data flows that have the correct policy applied. A crypto map can be applied on a main/physical or tunnel interface (with certain restrictions) and performs IPsec protection before interface encapsulation.
As an alternative to a crypto map, Cisco IOS also allows a tunnel interface with tunnel protection. This is a logical interface that represents the source and destination endpoints of the tunnel. The tunnel interface interconnects the transport network (the network that the tunnel source and destination will use) and the overlay network (the traffic that will transverse within the tunnel). The tunnel interface allows various forms of encapsulation (defined as modes); although we will focus on generic routing encapsulation (GRE) or IPsec as the modes of encapsulation, other modes can be used, such as IP-in-IP, Distance Vector Multicast Routing Protocol (DVMRP), or IPv6-in-IPv4. However, these will not be discussed, for they are not relevant to using IKEv2 or IPsec.
Generic routing encapsulation (GRE) is covered, as well as the reasons why this is needed when using non-IP protocols or multicast. The overhead that is incurred by GRE is discussed, along with its benefits, such as mixed mode and dual stack for passing both IPv4 and IPv6 over a single IPsec Security Association.
The two modes that are relevant within this chapter and the remaining book are tunnel mode GRE and tunnel mode IPsec: both of these modes allow for the tunnel to become protected (by IPsec) by applying what is known as tunnel protection.
Tunnel protection can be applied only to a tunnel interface. The protection profile specifies the security policy that is applied to the IPsec Security Association, including how to protect, the protocol, the mode (transport or tunnel) and the cryptographic algorithms used. Unlike crypto maps, tunnel protection performs IPsec protection after interface (tunnel) encapsulation.
To highlight the differences between using a crypto map and tunnel protection, we can take two examples: the first uses tunnel protection, where the tunnel protection uses Encapsulation Security Payload in transport mode and is applied to a GRE tunnel interface. Traffic that passes into the tunnel is encapsulated within GRE and is then encrypted by the tunnel protection.
Figure 4-1 illustrates the behavior when a tunnel interface with tunnel protection is used. Note that since the encapsulated packet will be IP, the protocol type within the GRE header, which denotes the encapsulated traffic, is described with the ethertype value (0×0800), which is IPv4.
In contrast, if a crypto map is applied to a GRE tunnel interface (with no tunnel protection), we see that traffic is protected by the crypto map as soon as it enters the tunnel interface; because tunnel mode is used, the entire packet is encrypted. This traffic is then GRE encapsulated, with the outer IP headers being composed of the GRE tunnel source and destination addresses. Note that in Cisco IOS version 15 code and later this is an invalid configuration on Cisco IOS and will result in an error when the crypto map is applied to the tunnel interface. Before Cisco IOS version 15 code it was possible to apply a crypto map to a tunnel interface, but by default tunnel mode would also be enabled, rather than transport mode (even when the ipsec transform-set used transport mode). This is because RFC 4301 has the strict requirement that an IPsec gateway uses transport mode only for locally sourced traffic. This example is included only to illustrate the behavior when using crypto maps.
Figure 4-2 illustrates the contrasting behavior, where you can see that the original payload is encrypted and then GRE encapsulated.
You will learn why Cisco moved from using legacy crypto maps, which will help you understand why the VPN architecture was changed on Cisco IOS with the introduction of tunnel interfaces. After reading this chapter, you will be aware of the different types of tunnel interfaces, which will make you able to know where to position Virtual Tunnel Interfaces (VTI) or GRE Tunnel Interfaces in a static or dynamic model.
For each interface type, the chapter describes how traffic is encapsulated and the effect that this has on the route lookup; you will learn how packets move through the encapsulation/decapsulation engines and what effect this has on the route lookup.
The way to enable IPsec on the interface is described, with the various tunnel encapsulation modes. Static and dynamic tunnel interfaces will be covered, which will let you understand where to position each.
Virtual Routing and Forwarding (VRF) is introduced, along with the ability of limiting passing traffic between VRFs using tunnel interfaces.
This chapter introduces command line interface outputs to help you understand the technologies when virtual private networks are configured on Cisco IOS and IOS-XE. In the rest of this chapter, IOS will imply IOS and IOS-XE.
Modes of Encapsulation
The method of encapsulation is defined by the mode of the tunnel; the following section describes GRE when using IPsec tunnel and transport mode.
GRE Encapsulation
Generic routing encapsulation (defined by RFC 2784 and extended by RFC 2890) provides a simple mechanism to encapsulate packets of any protocol (the payload packets) over any other protocol (the delivery protocol) between two endpoints. GRE places its own header (4 bytes plus options) between the payload packet and the delivery header. Figure 4-3 shows the structure of the GRE header.
The C bit indicates the presence of the 16-bit (2-byte) Checksum field (one’s complement of the GRE header and payload) and 16 bits (2 bytes) of padding (Reserved1). The K bit is set if the 32-bit (4-byte) Key field is present; it allows for multiplexing traffic flows across GRE tunnels and is often used to differentiate traffic sourced from or destined to a specific tunnel interface. The S bit is set if the 32-bit (4-byte) Sequence Number field is present; it enables in-order delivery of packets.
A common case is GRE over IPv4 or IPv6 (GRE/IP for short). GRE/IP encapsulation results in a new IP packet being generated on the router, with the local GRE endpoint IP address as the source and the remote GRE endpoint IP address as the destination. The protocol number in the outer IP header is set to 47 (0×2F). The outer IP header is either IPv4 or IPv6, depending on whether the endpoint addresses are defined as IPv4 or IPv6.
With GRE/IP, the overhead compared to the original packet is:
4 bytes (+ GRE options) for the GRE header,
20 bytes (+ IP options) for the outer IPv4 header (GRE/IPv4), or
40 bytes (+ extension headers) for the outer IPv6 header (GRE/IPv6).
Figure 4-4 shows the encapsulation of a UDP over IPv4 packet into GRE/IPv4. The UDP traffic endpoints are 10.x.x.x, and the GRE tunnel endpoints are 172.16.x.x.
A later subsection in this chapter, “Multipoint GRE,” explains the concept of GRE-based multipoint interfaces (known as mGRE). A common misconception is that the mGRE overhead is 28 bytes, as opposed to 24 bytes for plain GRE overhead. In fact there is no such thing as mGRE overhead; the misconception comes from the frequent use of a GRE tunnel key with a multipoint interface for multiplexing purposes.
GRE over IPsec
In GRE over IPsec (usually written GRE/IPsec for short), data packets are first encapsulated within GRE/IP, which results in a new IP packet being created inside the router. This packet is then selected for encryption (the traffic selector being GRE from local to remote endpoint IP address), and encapsulated into IPsec. The actual encapsulation depends on whether tunnel or transport mode is used. Since a new IP header has already been added, IPsec transport mode is generally used to keep the overhead to a minimum (with it there is no need to add another 20-byte IP header); however this is possible only if the GRE and IPsec traffic terminate on the same endpoints.
IPsec Transport Mode with GRE over IPsec
With GRE over IPsec transport mode, a plaintext IPv4 or IPv6 packet is encapsulated in GRE/IP and then protected by IPsec for confidentiality and/or integrity protection; the outer IP header with tunnel source and destination addresses helps route the packet correctly.
The GRE over IPsec transport mode overhead compared to the original packet is by default the GRE plus the crypto overhead, along with the outer IPv4 or IPv6 header, which is the tunnel source and destination (see chapter 15, “IPsec Overhead and Fragmentation,” for more details).
Figure 4-5 shows the encapsulation of a UDP over IPv4 packet using GRE over IPsec transport mode. The UDP traffic endpoints are 10.x.x.x, and the IPsec tunnel endpoints are 172.16.x.x. The protocol field in the outer IP header is set to 50 (0×32) for Encapsulation Security Payload.
IPsec Tunnel mode with GRE over IPsec
With GRE over IPsec tunnel mode, a plaintext IPv4 or IPv6 packet is encapsulated into GRE and then into another IPv4 or IPv6 packet containing the tunnel source and destination IP addresses. This is protected by IPsec for confidentiality and/or integrity protection, with finally an additional outer IP header being used as the tunnel source and tunnel destination to route the traffic to the destination.
The IPsec tunnel mode overhead compared to the original packet is:
40 bytes (more if IP options are present) for the outer and inner IPv4 headers, or
80 bytes (more if extension headers are present) for the outer and inner IPv6 headers, plus the GRE (4 byte) and crypto overhead (see chapter 15, “Computing the IPsec Overhead”).
Figure 4-6 shows the encapsulation of a UDP over IPv4 packet into Encapsulation Security Payload tunnel mode with GRE transport. The UDP traffic endpoints are 10.x.x.x, and the IPsec tunnel endpoints are 172.16.x.x. The protocol field in the outer IP header is set to 50 (0×32) for Encapsulation Security Payload. Note that since the encapsulated packet will be IP, the protocol type within the GRE header, which denotes the encapsulated traffic, is described with the ethertype value (0×0800), which is IPv4.
It should be noted that the inner IP header, which is placed after the Encapsulation Security Payload header and before the GRE header, is encrypted and can’t be used in traffic routing decisions. This header is really redundant and serves little useful purpose. The only case when the inner IP header is needed, and so GRE over IPsec tunnel mode is used, occurs when DMVPN is used with mGRE and multiple spokes are behind the same PAT device. In this case the inner IP header can be used to differentiate the spokes. It should be noted that this limitation does not occur when using IKEv2 with virtual-access interfaces, as they are inherently point-point. For this reason GRE/IPsec in transport mode should be used where possible to save of 20 bytes overhead for IPv4 and 40 bytes for IPv6.
Traffic
There are a number of limitations with the traffic that can be protected when using encapsulation modes and their method of protection. The following sections will describe the limitations and benefits of the various methods of protection.
Multicast Traffic
When multicast is used, it is possible that if a device has multiple peers and as a result has security associations from multiple sources, these can conflict with each other. For multicast traffic, there is the issue of multiple destination systems associated with a single SA.
For this reason, a method or system is required to coordinate among all multicast devices the ability to select an SPI or SPIs on behalf of each multicast group and then communicate the group’s IPsec information to all of the legitimate members of that multicast group via some mechanism.
When legacy site-to-site crypto maps on Cisco IOS are used, the transport of multicast data traffic over the VPN tunnel will be prevented; however, locally sourced multicast traffic will be permitted, enabling peering across the VPN by using a multicast-based routing protocol (like OSPF or EIGRP, for example).1
1 See Cisco bug CSCtq94342 Self-originated, multicast traffic handling through IPsec tunnel, for details.
Specific standards have been developed for this, such as the Multicast Group Security Architecture (RFC 3740) and the Group Domain of Interpretation (RFC 6407), and Cisco’s GET VPN solution implements and extends those standards. However, this technology introduces specific requirements and constraints in terms of network architecture, such as the use of a private transport network.
Another possibility is to encapsulate multicast into GRE (using the same principle as for mixed mode and dual stack).
Fortunately, virtual IPsec interfaces (known as VTI and described in the next section) do not have this limitation, as their point-to-point nature and any-to-any SA negotiation enable multicast to flow across a pure IPsec tunnel without resorting to GRE. This means that multicast-based routing protocol neighborships as well as multicast data traffic forwarding become possible using native IPsec virtual interfaces.
Non-IP Protocols
In some cases, it is necessary to transport non-IP traffic over an IPsec VPN. Examples include the Cisco Discovery Protocol (CDP) or the Next Hop Resolution Protocol (NHRP) that enables dynamic mesh capabilities in DMVPN and FlexVPN.
Transporting non-IP protocols cannot be achieved using native IPsec, for it is only meant to transport IPv4 or IPv6 traffic by definition of the traffic selectors. GRE is again the solution to this problem: By encapsulating non-IP protocols with GRE, IPsec can then be used to protect this traffic.
This is why GRE encapsulation is mandatory in dynamic mesh scenarios that rely on NHRP, even though it may seem like native IPsec would be sufficient.
Table 4-1 summarizes the protocols that can be transported over the types of IPsec tunnels mentioned in this chapter (the crypto map row represents IPsec tunnel mode without prior GRE encapsulation and without the use of a VTI).
The Demise of Crypto Maps
The original implementation of IPsec VPNs used on Cisco IOS was known as crypto maps. The concept of configuring a crypto map was closely aligned to the IPsec protocol, with traffic that was required to be encrypted being defined in an access control list. This list was then referenced within an entry in the crypto map along with the IPsec cryptographic algorithms within the transform set.
This configuration could become overly complex, and when long access control lists were used, it was very common for mismatched access control entries to result in the creation of a security association that did not include all traffic that was intended to be protected. As a result, traffic that should have been protected was sent in the clear.
It is also the case that the access control list must be updated to reflect new networks if additional networks must be protected. If a VPN Gateway is using crypto maps and has 100 peers, a new access control entry is required for every remote prefix on the gateway and every peer, resulting in a potential administrative nightmare.
The crypto map is applied to an interface and is activated when traffic is sent or received over the interface. The result is limited flexibility if multiple interfaces are to be used or if for some reason the interface to which the crypto map is applied is not used to route the traffic.
The concept of logical tunnel interfaces was developed, which would have a crypto map applied to it. (This crypto map is not user configurable; however, the attributes that it uses are referenced from the user-configured IPsec profile used to protect the tunnel.) Any traffic sent or received on this logical interface would be protected by IPsec. This allows for traffic routing to be used to send traffic with the logical tunnel being the next hop and results in simplified configurations with greater flexibility for deployments. When the requirement for a user to configure what traffic was to be protected is removed, it reduces the chances of misconfigurations, which frequently occurred with manual configurations of access control lists with crypto maps.
On the Cisco Aggregation Services Routers (ASR), for every line or access control entry (ACE) in an access control list, a ternary content-addressable memory (TCAM) entry will be used. TCAM has a limited number of entries, and for crypto maps that contain a large number of ACEs, the TCAM can become exhausted. Tunnel protection uses only a single TCAM entry and allows for a larger number of IPsec Security Associations to be established compared to using crypto maps.
Crypto maps cannot natively support the use of MPLS, so the use of tunnel interfaces allows MPLS to be incorporated into a configuration.
Interface Types
When tunnels are used with IPsec, there are two types of tunnel interface encapsulation modes: pure IPsec or GRE.
Virtual Interfaces: VTI and GRE/IPsec
IPsec tunnels can be set up statically or dynamically using virtual interfaces of type VTI (Virtual-Tunnel Interface) or GRE/IPsec. These types of interfaces already existed in legacy IKEv1, and their use has been extended in FlexVPN.
The difference between the two interface types is the sequence of encapsulation: VTI (tunnel mode ipsec {ipv4 | ipv6}) carries IPv4 or IPv6 traffic directly within IPsec tunnel mode, while GRE/IPsec (tunnel mode gre {ip | ipv6}) first encapsulates traffic within GRE and a new IP header before encapsulating the resulting GRE/IP packet within IPsec transport mode.
For each type of virtual interface, two flavors are available: static (interface tunnel number) or dynamically instantiated (interface virtual-access number, dynamically created from a statically configured template-interface, interface virtual-template number type tunnel). You can think of virtual-template interface as a configuration template from which the virtual-access (VA) interfaces are dynamically cloned/instantiated.
In the rest of this section, we will simply refer to a “virtual interface” or “tunnel interface” when the described behavior remains the same regardless of the type (VTI or GRE/IPsec) and nature (static or dynamic) of the interface.
A virtual interface generally represents a point-to-point link that uses a specific protocol between two endpoints. The tunnel endpoints are configured using the tunnel source (local endpoint) and tunnel destination (remote endpoint) commands. Multipoint interfaces (mentioned at the end of this section) are the exception, for they do not have a remote endpoint configured and represent a single entry point into multiple point-to-point links.
Traffic Selection by Routing
With a virtual interface, outgoing traffic gets selected for encapsulation when it is routed through the interface, and incoming traffic from the VPN gets injected into the router after decapsulation with the tunnel as input interface. In order to achieve traffic selection by routing, the virtual interface must be a layer 3 interface with an IP address configured on it (called the tunnel address) and static or dynamic routes to the remote prefixes must be present in the routing table, with a next hop that is seen as directly connected through the virtual interface (that is, the next hop must be in the same subnet as the tunnel IP address).
The following example shows a simple static GRE tunnel configuration. The traffic flows from the local LAN (10.10.1.0/24) to the remote LAN (10.10.210.0/24). A static route to the remote LAN has been configured with the IP address of the tunnel interface on the remote GRE endpoint as the next hop.
Router#show running-config interface Tunnel0
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source Ethernet0/0
tunnel destination 209.165.200.225
end
Router#show running-config | include ip route
ip route 0.0.0.0 0.0.0.0 209.165.201.2
ip route 10.10.210.0 255.255.255.0 10.0.0.2
Router#show ip route 10.10.210.99
Routing entry for 10.10.210.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.2
Route metric is 0, traffic share count is 1
Router#show ip route 10.0.0.2
Routing entry for 10.0.0.0/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via tunnel0
Route metric is 0; traffic share count is 1
Consider an inbound IP packet from the local LAN (source address 10.10.1.99) that is destined to the remote LAN (destination address 10.10.210.99). Figure 4-7 illustrates how this packet flows inside the router (plain line) as opposed to a packet destined to an address on the WAN (dotted line).
1. The packet enters through the LAN interface.
2. The route lookup for the destination (10.10.210.90, remote LAN) yields a next hop of 10.0.0.2, which is seen as directly connected on the tunnel interface (10.0.0.0/30).
3. The packet is handed over to the tunnel interface and the encapsulation code.
4. The packet is consumed during encapsulation (GRE/IPv4 in this case), and a new IP packet is created with the configured tunnel endpoints as its source and destination.
5. The new packet goes through the normal routing process.
6. The route lookup for the destination (209.165.200.225) yields the WAN ISP router as the next hop on the WAN interface.
7. The GRE packet is forwarded over the WAN interface.
Note that the source address is not taken into consideration when the traffic is selected, but only the destination address. This differs from what happens, for example, with IPsec encapsulation using a static crypto selector (crypto map with match address access-list).
Figure 4-8 shows the packet headers before and after encapsulation.
Static Tunnel Interfaces
Static virtual interfaces (IPsec tunnel or GRE/IPsec) can be used on initiators and responders; these interfaces remain in the configuration at all times and must specify the address of the peer VPN endpoint (tunnel destination peer-address). The following example illustrates a sample static VTI configuration.
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel destination 209.165.200.225
tunnel protection ipsec profile default
When using the FlexVPN client profile feature (crypto ikev2 client flexvpn) (which will be described in chapter 10, “FlexVPN Client”), the peer address can optionally be set to dynamic. In this instance, the interface still remains in the configuration, and the peer address is populated at run time, based on the client profile configuration and tracking states.
Dynamic Tunnel Interfaces
Dynamic interfaces (IPsec tunnel or GRE/IPsec) are a responder-only feature, based on virtual-template interfaces that act as a template for dynamically created tunnels. A successful IKEv2 negotiation triggers the cloning of a virtual-template into a virtual-access interface (interface Virtual-Access number) that represents a point-to-point link to the remote peer, which is then protected by IPsec. The virtual-access interface remains up as long as the IPsec tunnel is up and gets deleted along with the corresponding IKE and IPsec security associations when the IPsec session is torn down.
Note
All virtual-template interfaces used in FlexVPN are declared as type tunnel, meaning that the instantiated virtual-access interfaces behave similar to static tunnel interfaces (interface Tunnel number): they perform some sort of encapsulation, can be configured with VRF (see later in this chapter), and generally support the same interface features.
Dynamic interfaces enable hub-and-spoke scenarios where the hub has a single virtual-template with the peer VPN endpoint left unspecified (no tunnel destination statement), while each spoke has a static tunnel interface that is configured with the hub IP address as the tunnel destination. In multi-homed scenarios, the local VPN endpoint (tunnel source statement) can also be left unspecified and get populated automatically based on the local address that the peer is connecting to. The following example shows a sample Virtual-Template (dynamic VTI) configuration.
interface Loopback1
ip address 10.0.0.1 255.255.255.255
interface Virtual-Template1 type tunnel
ip unnumbered Loopback1
tunnel mode ipsec ipv4
tunnel protection ipsec profile default
While the virtual template appears in the output of show running-config, the virtual-access interfaces do not. A specific command exists (show derived-config) that displays the configuration equivalent for the active virtual-access interfaces. The derived-config exists only at run time, is derived from the configuration on the virtual-template and from the IPsec session parameters, and is never written to the (non-volatile) NVRAM configuration, which would allow the configuration to be persistent even on a reload.
Note that the tunnel mode could be set to auto, and the resulting configuration applied on the cloned virtual-access interface would be based on what the peer proposes (tunnel mode gre/ipsec ipv4/ipv6).
The following example shows the derived config for a virtual-access interface based on the above virtual-template configuration. The highlighted lines have been automatically added during cloning.
router#show derived-config interface virtual-access 1
Building configuration...
Derived configuration : 225 bytes
interface Virtual-Access1
ip unnumbered Loopback1
tunnel source 209.165.200.225
tunnel mode ipsec ipv4
tunnel destination 209.165.201.1
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
end
sVTI and dVTI
In the case of pure IPsec tunnel encapsulation (without GRE), one refers to a statically configured tunnel interface as an sVTI (static VTI) and to a virtual-template as a dVTI (dynamic VTI). A single site-to-site tunnel is typically sVTI-to-sVTI, while a hub-and-spoke setup is typically sVTI-to-dVTI, with the dVTI on the hub. In addition, a feature called multi-SA dVTI provides support for interoperating with non-VTI-compatible peers (for example, those using legacy crypto maps), where the dVTI will present a mirror image of the traffic selectors requested by the initiator and can terminate multiple IPsec Security Associations from the same peer on the same virtual-access interface.
Multipoint GRE
A particular type of GRE encapsulation is multipoint GRE (mGRE, tunnel mode gre multipoint) where a single static GRE tunnel interface is used as the endpoint for multiple site-to-site tunnels. DMVPN is based on this mode and uses a single interface on each hub as well as on each spoke to terminate all static and dynamic tunnels.
FlexVPN does not rely on multipoint interfaces.
The following example shows a sample spoke-side multipoint GRE/IPsec interface. The mGRE-specific configuration statements are highlighted.
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
ip nhrp network-id 1
ip nhrp nhs 10.0.0.251 nmba 209.165.200.225 multicast
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile default
An mGRE interface is essentially a GRE tunnel interface that has lost its point-to-point nature and acts as if it is directly connected to a cloud of remote mGRE interfaces. The tunnel IP addresses of all mGRE interfaces in that cloud are part of a single subnet, and their IP addresses are all seen as directly connected, as they would be (for example) on an Ethernet link.
This is made possible by the use of the Next Hop Resolution Protocol (NHRP), which acts as a resolution mechanism between a peer’s tunnel address (the IP address configured on the peer’s mGRE interface) and the mGRE endpoint address on that peer, called the Non-Broadcast Multiple Access (NBMA) address.
The term “non-broadcast” expresses the fact that it is not possible to simply send a request containing the tunnel address being resolved to all possible peers and expect the owner of that address to reply, as the mGRE endpoints are not necessarily part of the same broadcast domain: they may, for example, be reachable through the Internet, dispersed across a large corporate network, or reachable over different interfaces and media.
Consider a packet flowing from the local LAN to the LAN of one of the peers on the mGRE interface in the example above. Figure 4-9 shows the different steps in performing the mGRE encapsulation. In this simplified example, we assume that the necessary NHRP mappings are already populated in the NHRP cache and that a routing protocol is used to advertise prefixes reachable over mGRE.
1. The packet enters through the LAN interface with source 10.10.1.99 and destination 10.10.3.99.
2. The route lookup for the destination (10.10.3.99) yields a next hop of 10.0.0.3, which is seen as directly connected on the tunnel interface (10.0.0.0/24).
3. The multipoint GRE code performs a lookup in the NHRP cache to resolve the remote tunnel address (10.0.0.3) into the corresponding NBMA address (198.51.100.9).
4. The original packet is consumed during encapsulation, and a new GRE/IP packet is created with the WAN interface address as its source and the remote NBMA address as its destination.
5. The route lookup for the destination (198.51.100.9) yields the WAN ISP router as the next hop on the WAN interface.
6. The GRE packet is forwarded over the WAN interface.
Note that Figure 4-9 describes mGRE encapsulation from a purely functional standpoint; in practice, Cisco Express Forwarding (CEF) accelerates steps 2 to 5 by setting up adjacencies on the tunnel interface based on the entries in the NHRP cache (to avoid a table lookup for every packet) and by prepopulating the Forwarding Information Base (FIB) with a complete output chain for the remote destinations.
Tunnel Protection and Crypto Sockets
All virtual-interface types mentioned so far perform some form of IPsec encapsulation. This is achieved by configuring the tunnel protection statement on the VTI or GRE/IPsec tunnel interface. This command applies a construct called IPsec profile to the interface and ensures that the crypto layer will be hit by packets traversing the interface (immediately in the case of VTI, and right after GRE encapsulation in the case of GRE/IPsec).
The following example shows a GRE/IPsec tunnel configuration (since the default tunnel mode is tunnel mode gre ip, the command does not appear in the running configuration). The default IPsec profile is applied and links to the default IKEv2 profile.
crypto ipsec profile default
set ikev2-profile default
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source Ethernet0/0
tunnel destination 209.165.200.225
tunnel protection ipsec profile default
The tunnel protection feature relies on a mechanism called crypto sockets that represents crypto sessions in a way similar to network sockets: there are listening sockets and established sockets, which are dynamically created and deleted on demand. Every IPsec VPN session (bundle of IKE and IPsec Security Associations with a specific peer) results in a separate crypto socket.
The following example shows sample output of show crypto sockets for the interface configuration in the previous example. The IPsec tunnel is established (one active socket), and IPsec is listening for incoming sessions (one listening socket).
router#show crypto sockets
Number of Crypto Socket connections 1
Tu0 Peers (local/remote): 209.165.201.1/209.165.200.225
Local Ident (addr/mask/port/prot): (209.165.201.1/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (209.165.200.225/255.255.255.255/0/47)
IPSec Profile: "default"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Crypto Sockets in Listen state:
Client: "TUNNEL SEC" Profile: "default" Map-name: "Tunnel0-head-0"
Another convenient command when working with IPsec VPNs on IOS is show crypto session. It displays the active IKEv1 and IKEv2 security associations (SAs) as well as the active IPsec Security Associations. The following example illustrates this command applied to the example above.
router#show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 209.165.200.225 port 500
IKEv2 SA: local 209.165.201.1/500 remote 209.165.200.225/500 Active
IPSEC FLOW: permit 47 host 209.165.201.1 host 209.165.200.225
Active SAs: 2, origin: crypto-map
While those two commands may look similar at first sight, they actually represent two different functions. Crypto sockets are a representation of the IPsec state and are independent of the IKE layer. They are used by the tunnel protection mechanism; however, a legacy crypto map configuration would not rely on them, and show crypto sockets for a crypto map tunnel would not return any output. On the other hand, show crypto session offers a summarized view of the IKE and IPsec Security Associations in the system for each peer, regardless of the origin of those SAs, whether crypto map or tunnel protection.
Implementation Modes
This section describes the ability of GRE and native IPsec tunnel encapsulation modes to carry IPv4 and/or IPv6 traffic and the ability to automatically detect the tunnel encapsulation mode and IP transport type on an IKEv2 responder.
Dual Stack
It is now common for devices to support both IPv4 and IPv6 protocols at the same time. Many operating systems now ship with both protocols enabled by default, and networks that are looking to transition from IPv4 to IPv6 commonly require both protocols to coexist, allowing devices to access both IPv4 and IPv6 content in parallel.
As you learned from chapter 2, “IKEv2: The Protocol”, multiple traffic selectors can be created within the IKEv2 CREATE_CHILD_SA exchange, thus allowing a single IPsec Security Association to transport protocols of different types. This can allow both IPv4 and IPv6 traffic to be created using a single IPsec Security Association. The ability to tunnel both IPv4 and IPv6 traffic using a single SA over IPv4 or IPv6 transport is referred as dual stack support.
Cisco IOS allows for dual stack support on IKEv2 gateways when using the Cisco AnyConnect client; however the transport protocol used must be IPv4, and the encapsulation must be GRE. However, both IPv6 and IPv4 addresses can be dynamically obtained over this, and data can pass over the relevant traffic selectors. Dual stack is achieved when the AnyConnect client advertises that it supports this ability by sending a Vendor ID payload of type Cisco AnyConnect GRE Mode. The IKEv2 headend will then allocate the AnyConnect client an IPv4 or IPv6 (or both if required) address via Configuration Payload. If the AnyConnect client requests both an IPv4 and an IPv6 address, then traffic selectors for both IPv4 and IPv6 traffic will be requested, and the headend will install a single traffic selector for IPv4 using GRE between both hosts. All traffic will run over this SA.
It should be noted that Cisco IOS naturally allows for the transportation of both IPv4 and IPv6 traffic when GRE encapsulation is used with IPsec. Because GRE is used as the encapsulation mechanism, it can inherently encapsulate either protocol and will only require a single IPsec security association that contains the tunnel source and destination IP addresses and the protocol, which is GRE (47).
Mixed Mode
On Cisco IOS, virtual interfaces implementing IPsec tunnel mode with IPv4 (tunnel mode ipsec ipv4) or IPv6 (tunnel mode ipsec ipv6) transport will by default negotiate IPsec Security Associations that protect the same protocol version as the one used for transport (for instance, an IPsec virtual interface using IPsec over IPv4 will negotiate protection only for IPv4 traffic using IP protocol 4 (IPv4 0×04), whereas IPv6 uses IP protocol 41 (0×29).
Since 15.6(1)T, Cisco IOS can use a tunnel interface configured in IPsec tunnel mode with IPv4 to create IPv6 Security Associations, or IPsec tunnel mode with IPv6 to create IPv4 Security Associations by using the tunnel mode ipsec ipv4 v6-overlay and tunnel mode ipsec ipv6 v4-overlay commands respectively. This allows an IPv4 overlay network to be extended over an IPv6 transport network, or an IPv6 overlay network to be extended over an IPv4 transport network when IPsec tunnel mode virtual interfaces are used.
The following example illustrates the configuration used for the creation of an IPv4 tunnel over an IPv6 transport using a VTI.
interface Tunnel0
ip address 192.168.1.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv6 v4-overlay
tunnel destination 2001:DB8::2
tunnel protection ipsec profile default
The following illustrates the established session. The IKEv2 SA is created between the IPv6 addresses, and note that the created IPsec Security Associations are using IPv4 traffic selectors (0.0.0.0/0.0.0.0).
Router#show crypto session
Crypto session current status
Interface: Tunnel0
Profile: default
Session status: UP-ACTIVE
Peer: 2001:DB8::2 port 4500
Session ID: 1
IKEv2 SA: local 2001:DB8::1/500 remote 2001:DB8::2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto-map
Figure 4-10 illustrates an IPv4 packet being encapsulated within an IPv6 tunnel when IPsec tunnel mode is used.
To configure an IPv6 overlay over IPv4 tunnel, the following tunnel mode must be used:
tunnel mode ipsec ipv4 v6-overlay
The following example illustrates the configuration used for the creation of an IPv6 tunnel over an IPv4 transport that uses a VTI.
interface Tunnel0
ipv6 address 2001:DB8::1/112
ipv6 enable
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4 v6-overlay
tunnel destination 192.168.1.2
tunnel protection ipsec profile default
The following illustrates the established session. The IKEv2 SA is created between the IPv4 addresses, and note that the created IPsec Security Associations are using IPv6 traffic selectors (::/0).
Router#show crypto session
Crypto session current status
Interface: Tunnel0
Profile: default
Session status: UP-ACTIVE
Peer: 192.168.1.2 port 4500
Session ID: 1
IKEv2 SA: local 192.168.1.1/500 remote 192.168.1.2/500 Active
IPSEC FLOW: permit ipv6 ::/0 ::/0
Active SAs: 2, origin: crypto-map
Figure 4-11 illustrates an IPv6 packet that is encapsulated within an IPv4 tunnel when IPsec tunnel mode is used.
Since 15.2(3)T, Cisco IOS (when acting as remote access VPN headend) can support sending IPv4 traffic over an IPv6 Security Association when IPsec tunnel mode is used as the encapsulation protocol (tunnel mode ipsec IPv6), or IPv6 traffic over an IPv4 Security Association when IPsec tunnel mode is used as the encapsulation protocol (tunnel mode ipsec IPv4).
There are a number of caveats to using this behavior: the IOS device must be using IKEv2, and the tunnel interface must be configured as a dynamic virtual-tunnel interface.
To enable activation of mixed mode, the set mixed-mode command must be enabled under the IPsec profile.
Note that when using a tunnel interface with GRE encapsulation, the limitation of requiring a certain version of IOS to transport IPv4 traffic within a IPv6 tunnel or IPv6 traffic within an IPv4 tunnel does not occur. When GRE encapsulation is used with tunnel protection, a single IPsec Security Association will be created that can then transport both IPv4 and IPv6 traffic within the encapsulated tunnel. This is achieved by using GRE/IPsec, where IPv4 and IPv6 are both first encapsulated into GRE and then into either IPv4 or IPv6 using IPsec transport mode. GRE acts as an abstraction layer that isolates the inner protocol from the IPsec layer, which handles only the protection of GRE packets over either IPv4 or IPv6 (depending on the tunnel endpoints).
Auto Tunnel Mode
Cisco IOS and IOS-XE (since 15.4(2)T) allows a router acting as a IKEv2 aesponder to use Auto Tunnel Mode (tunnel mode auto). In this mode, the headend will mimic the mode presented by the peer and respond by creating an IPsec Security A ssociation that uses the same attributes (the choice being GRE or IPsec with IPv4 or IPv6). This allows a headend to serve multiple clients of different tunnel types that use both IPv4 and IPv6 with minimal configuration.
VRF-Aware IPsec
This section describes VRF as it applies to IPsec.
VRF in Brief
Virtual Routing and Forwarding (VRF) technology makes it possible to virtualize layer 3 forwarding on a router and implement multiple separate routing domains on a single device. It enables segregation of traffic flows from different parts of the network or from different customers (known as multitenant) as well as overlapping addresses. A VRF-aware router will maintain separate routing instances with separate information per VRF, including a separate Routing Information Base (RIB), Forwarding Information Base (FIB), ARP table, and routing protocol information. The default VRF on a router is global. VRF can be encountered in two forms: MPLS VPN and VRF-Lite.
A VRF needs to be defined and given a name by using the commands ip vrf (deprecated, IPv4 only) or vrf definition (multiprotocol, supporting the IPv4 and IPv6 address-families). Each physical and logical (for example, loopback or tunnel) interface on the device can be assigned to a single VRF by using the commands ip vrf forwarding (deprecated, for IPv4-only VRF) or vrf forwarding (multiprotocol supporting IPv4 and IPv6). By default, every interface belongs to the global VRF. Traffic coming in through an interface is forwarded according to the routing table of the VRF configured on the interface.
Without specific configuration, all traffic will leave the router through the same VRF as it entered. Packets can enter the router through one VRF and leave through another in a number of situations:
encapsulation/decapsulation (described later in this section)
route leaking, where routes are set up statically or imported via BGP, with the next hop pointing to an interface in another VRF
route replication, which is used with Easy Virtual Network (EVN), where prefixes are copied directly between VRFs using the Routing Information Base (RIB)
The following example shows the definition of two VRFs named red and blue. Figure 4-12 illustrate the independent forwarding of traffic within the two VRFs. The overlap between the addresses on Ethernet0/1 and Ethernet1/1 has no effect, because they belong to separate routing domains.
vrf definition blue
address-family ipv4
exit-address-family
vrf definition red
address-family ipv4
exit-address-family
interface Ethernet0/1
vrf forwarding red
ip address 172.16.10.1 255.255.255.0
interface Ethernet0/2
vrf forwarding red
ip address 172.16.20.1 255.255.255.0
interface Ethernet1/1
vrf forwarding blue
ip address 172.16.10.1 255.255.255.0
interface Ethernet1/2
vrf forwarding blue
ip address 172.16.30.1 255.255.255.0
s1#show ip route vrf red
Routing Table: red
[...]
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.10.0/24 is directly connected, Ethernet0/1
L 172.16.10.1/32 is directly connected, Ethernet0/1
C 172.16.20.0/24 is directly connected, Ethernet0/2
L 172.16.20.1/32 is directly connected, Ethernet0/2
s1#show ip route vrf blue
Routing Table: blue
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.10.0/24 is directly connected, Ethernet1/1
L 172.16.10.1/32 is directly connected, Ethernet1/1
C 172.16.30.0/24 is directly connected, Ethernet1/2
L 172.16.30.1/32 is directly connected, Ethernet1/2
Features that offer support for VRF are called VRF aware. This can mean different things for different features; for instance, a VRF-aware SNMP MIB will provide separate results per VRF and may restrict access from inside a certain VRF to OIDs pertaining to other VRFs, or that if a feature is not VRF aware it cannot be used when accessed from a VRF aware interface.
VRF-Aware GRE and VRF-Aware IPsec
GRE is VRF aware, in the sense that the encapsulated (payload) and nonencapsulated (delivery) traffic may reside in different VRFs. This is achieved by proper configuration of the GRE tunnel interface (see below).
IPsec is also VRF aware, both with legacy crypto maps and VTI. The configuration differs slightly: legacy VRF awareness (not covered in this book) is based on IKE profiles and route leaking, while VTI only relies on the VRF configuration on the tunnel interface being the same as GRE. In general, encapsulation through a tunnel interface is VRF aware.
Throughout this book, we will refer to the VRF on which the nonencapsulated (pre-encaps or post-decaps) traffic resides as the IVRF or inside VRF, and to the VRF where encapsulated traffic resides as the FVRF or front-door VRF. The IP address configured on the tunnel interface (the tunnel address) resides in the IVRF, while the tunnel source and destination reside in the FVRF.
The IVRF of a tunnel interface is configured with the vrf forwarding name command. If the interface is {ip | ipv6} unnumbered to another interface, the two interfaces must reside in the same VRF (with the same vrf forwarding statements).
The FVRF on a tunnel is configured with the tunnel vrf name command.
Figure 4-13 illustrates VRF-aware GRE encapsulation.
VRF-Aware GRE over IPsec
GRE over IPsec is configured by adding a tunnel protection statement on a GRE tunnel interface (tunnel mode gre {ip | ipv6}). Even though the resulting packet contains both an IPsec and a GRE header, the two encapsulation steps do not occur at exactly the same stage: the tunnel interface still represents a tunnel that performs GRE encapsulation only, and the IPsec feature is set up to protect the resulting GRE packet.
In terms of VRF awareness, this means that the hop between IVRF and FVRF is performed by the sole GRE encapsulation, while the GRE/IP traffic is selected, encrypted, and decrypted by IPsec within the FVRF.
Figure 4-14 illustrates the VRF-aware GRE/IPsec packet flow; the only difference with Figure 4-13 is the addition of the IPsec post-encapsulation feature on the GRE tunnel interface.
Summary
By now you should be familiar with the modes of IPsec and the overhead that is generated when using transport mode or tunnel mode. You will also know that Generic Routing Encapsulation (GRE) is used for encapsulating non-IP protocols and what overhead using GRE incurs.
This chapter detailed the various implementation modes on Cisco IOS and explained how you can use mixed mode to transport IPv4 over IPv6 tunnel interfaces, or IPv6 over IPv4 tunnel interfaces. We also demonstrated how to use auto tunnel mode, whereby the tunnel mode and tunnel protection is automatically replicated from the incoming traffic selectors. Allowing for a single tunnel interface to be used by peers with different tunnel types.
Within this chapter we covered the building blocks that show how tunnel interfaces operate on Cisco IOS, and we described what tunnel modes you can configure for IPsec and the benefits that each brings. Virtual Tunnel Interfaces are used when GRE is not required. Static VTIs are used when the peer is known, while Dynamic VTIs are a responder-only feature and allow a virtual-access interface to be spawned from the virtual-template.
The method of route lookup and the ability for traffic to move between VRF’s when traversing a tunnel were described, along with the security benefits that this brings.