Chapter 10. FlexVPN Client
Introduction
This chapter introduces and explains the features relevant to the FlexVPN client. The FlexVPN client is a Cisco IOS router-based VPN client positioned for remote offices and mobile workers to provide VPN connectivity to the corporate headquarters. The FlexVPN client leverages the IKEv2 configuration and the FlexVPN building blocks discussed in the earlier chapters. FlexVPN client uses a point-to-point tunnel interface with native IPsec or GRE encapsulation to connect to the FlexVPN server and supports EAP as a local authentication method along with pre-shared key and certificate-based authentication methods.
The chapter covers the following main topics:
FlexVPN Client Overview
The FlexVPN client is a hardware-based VPN client compared to other VPN clients such as Cisco AnyConnect, Microsoft Windows IKEv2 client, and Strongswan that are software based. While a software VPN client provides VPN access to a single host, the hardware-based FlexVPN client acts as a VPN gateway and provides VPN access for multiple hosts behind the client as illustrated in Figure 10-1.
The FlexVPN client is positioned for remote offices and mobile workers, allowing for simplified deployments of a VPN, where the client could potentially connect to different VPN headends, depending on certain criteria such as route tracking, status of an SLA, or interface status. Services that are required for remote access solutions such as WINS, DNS, and DHCP and tightly integrated into the FlexVPN client and configuration can be pushed from the FlexVPN server using the IKEv2 configuration exchange that can integrate with DNS and DHCP. The client has a number of similarities to the features included with EzVPN. However, IKEv2 is used instead of IKEv1 in EzVPN.
EzVPN is a legacy Cisco technology that was aimed at small office home office (SOHO) workers who required secure remote connectivity. The Cisco router-based EzVPN client creates an IPsec tunnel to the VPN headend and also provides services, such as DNS and DHCP, for devices connected to the router such as PCs and phones.
The FlexVPN client feature can be used with any type of FlexVPN deployment, including point-to-point, hub-spoke, and dynamic mesh topologies. Because the FlexVPN clients features integrates into any feasible deployment scenario, this now allows for deployments that would have previously required custom scripting or were simply impossible to implement.
The FlexVPN client feature allows a VPN to be established between a tunnel interface on the FlexVPN client and a FlexVPN server. The FlexVPN client profile is configured on a client and associated with a tunnel interface; the tunnel destination will be dynamically obtained from the client profile. The tunnel interface does not have a defined static destination, which allows for the enhanced object tracking feature to integrate with the FlexVPN client and allows the peer to be dynamically chosen depending on the status of track events.
Routing can be implemented either by static routing, a dynamic routing protocol, or by IKEv2 routing. Since a virtual-access interface is dynamically created on the FlexVPN server when a client connects, should a routing protocol be used, the routing peering must occur over this virtual-access interface.
The FlexVPN client functionality implements a number of features that are proprietary to Cisco, such as the attributes pushed from the FlexVPN server in the IKEv2 configuration exchange. An indication that a device is a FlexVPN client is the sending of Vendor Identification (VID) payloads containing CISCO-DELETE-REASON and FLEXVPN-SUPPORTED in the IKE_SA_INIT exchange.
FlexVPN Client Building Blocks
The FlexVPN client uses the following key building blocks:
IKEv2 configuration exchange
Static point-to-point tunnel interface
FlexVPN client profile
Object tracking
NAT
IKEv2 Configuration Exchange
The FlexVPN client leverages the IKEv2 configuration exchange for the following:
Request IPv4/IPv6 address from the server subnet and other parameters required for remote access, such as DNS and WINS from the FlexVPN server
Learn the subnets protected by FlexVPN server in order to implement split tunneling
Advertise the routable subnets behind the FlexVPN client to the FlexVPN server that the server can redistribute
Exchange the tunnel address with the FlexVPN server in order to establish dynamic routing protocols such as BGP over the tunnel
Learn the FlexVPN servers that can used as backup
Static Point-to-Point Tunnel Interface
FlexVPN client uses a point-to-point tunnel interface to connect to the FlexVPN server. The tunnel interface is associated with a FlexVPN client profile that drives some of the tunnel configuration such as tunnel source and destination. The tunnel interface can use GRE or native IPsec encapsulation. GRE encapsulation enables dual-stack (IPv4 and IPv6 overlay) over IPv4 or IPv6 transport while the native IPsec encapsulation supports either IPv4 or IPv6 overlay (not both) over IPv4 or IPv6 transport, referred to as mixed mode. The tunnel IP address can either be statically configured or dynamically programmed with the IP address assigned by the FlexVPN server, which is enabled using the ip address negotiated command. The P2P tunnel interface allows applying features such as QoS, access control list, and firewall policy on the cleartext traffic in inbound and outbound directions. The features required on the encrypted traffic can be applied on the WAN interface.
FlexVPN Client Profile
The FlexVPN client profile is the central configuration construct that defines the peer list, tunnel initiation method, and advanced features, such as reactivate peer, backup gateways, and dial backup. The client profile references the tunnel interface and drives the dynamic configuration of tunnel source and destination based on the priority and availability of the WAN interfaces and the peers. The FlexVPN client profile is described in detail later in the chapter.
Object Tracking
The FlexVPN client leverages the Cisco IOS object-tracking infrastructure to support the various advanced features such as track-based tunnel activation, backup gateways, and dynamic tunnel source and destination configuration.
NAT
The network address translation (NAT) is applied on the FlexVPN client tunnel interface to translate the source address of the outbound cleartext traffic to the tunnel interface IP address, which is assigned by the FlexVPN server. This is useful when the hosts behind the FlexVPN client have private IP addresses that are not reachable beyond the FlexVPN client and hence are required to be translated to public IP address(es). The FlexVPN client can also apply NAT on the WAN interface for the Internet-bound, split tunnel traffic. Note that NAT must be explicitly configured on tunnel and outbound interfaces as needed.
FlexVPN Client Features
Following are some of the key features supported by FlexVPN client:
Dual stack support
EAP authentication
IKEv2 routing and dynamic routing protocol support
Support for EzVPN client and network extension modes
Advanced features
Dual Stack Support
The FlexVPN client supports dual stack using GRE encapsulation. The FlexVPN client tunnel interface with GRE encapsulation mode (tunnel mode gre) can carry IPv4 and IPv6 overlay traffic over either IPv4 or IPv6 transport and with native IPsec encapsulation mode (tunnel mode ipsec) can carry either IPv4 or IPv6 overlay traffic over either IPv4 or IPv6 transport.
EAP Authentication
In addition to pre-shared keys and certificate-based authentication methods, the FlexVPN client can authenticate using the EAP-MSCHAPv2, EAP-GTC, and EAP-MD5 methods. Note that when the FlexVPN client authenticates using EAP, the FlexVPN server must authenticate using a certificate-based method.
Dynamic Routing
In addition to static routing and IKEv2 routing where the FlexVPN client and server exchange routes using an IKEv2 configuration exchange, the FlexVPN client supports dynamic routing protocol over the VPN tunnel. The FlexVPN client and server are configured to exchange the tunnel addresses, using an IKEv2 configuration exchange to establish dynamic routing on the overlay, that is, allow routing peering between the tunnel addresses. Note that dynamic routing is useful when the FlexVPN client has routable subnets and connections to a number of FlexVPN servers.
Support for EzVPN Client and Network Extension Modes
The FlexVPN client supports the EzVPN client mode by configuring NAT on the tunnel interface and translating the source addresses of the cleartext outbound traffic to the tunnel IP address that is assigned by the server. This is useful when the client subnets use private IP addresses.
The FlexVPN client supports the EzVPN network extension mode by advertising the routable subnets to the server, using IKEv2 routing or dynamic routing.
Advanced Features
The FlexVPN client supports various advanced features such as dynamic peer list, dynamic tunnel source, tunnel activation, dial backup, and peer reactivation features, using the Cisco IOS object-tracking infrastructure.
Setting up the FlexVPN Server
The FlexVPN server must be configured to accept connections from FlexVPN clients and send the required configuration attributes via the IKEv2 configuration exchange. The acceptance of client connections is configured by creating a virtual-template that is associated with an IKEv2 profile. Clients successfully connecting to the FlexVPN server will create a virtual-access interface from the virtual-template. The attributes sent to the client are configured either within an IKEv2 authorization policy or gained from a RADIUS server using AAA. These attributes are requested by the client in the IKE_AUTH request and passed to the client from the server in the IKE_AUTH response.
The virtual-template interface can be implemented, using either GRE encapsulation or native IPsec (tunnel mode ipsec). The tunnel mode on clients must match that on the FlexVPN server or the FlexVPN server must be configured with auto-detection of tunnel encapsulation protocol and transport IP type as described in chapter 9 “FlexVPN Server.”
In addition to the standard attributes, such as IP address/prefix, IPsec attributes, and routes, the FlexVPN server supports the following attributes that can be derived via AAA and are pushed to FlexVPN clients via the IKEv2 configuration exchange.
Split-DNS
Backup gateway addresses
Default domain name
Domain name system (DNS)
Windows Internet name service (WINS)
Authentication of the FlexVPN client and server can be performed by EAP, pre-shared-keys, or certificates. If EAP is used, then only the client (being the initiator of the IKEv2 SA) can be authenticated by EAP and as per RFC 7296, the server must be authenticated using certificates. An implementation using EAP MUST also use a public key-based authentication of the server to the client before the EAP authentication begins.
EAP Authentication
The FlexVPN client supports EAP as a local authentication method and supports the EAP-MSCHAPv2, EAP-GTC, and EAP-MD5 methods. EAP, as a local authentication method, is configured in the IKEv2 profile as illustrated in the following example.
FlexClient(config-ikev2-profile)#authentication local eap ?
gtc eap method gtc credentials
md5 eap method md5 credentials
mschapv2 eap method mschapv2 credentials
<cr>
The EAP credentials can be statically configured in the IKEv2 profile.
FlexClient(config-ikev2-profile)#authentication local eap gtc ?
password EAP password
username EAP username
FlexClient(config-ikev2-profile)#authentication local eap md5 ?
password EAP password
username EAP username
FlexClient(config-ikev2-profile)#authentication local eap mschapv2 ?
password EAP password
username EAP username
If not configured in the IKEv2 profile, the user is prompted for EAP credentials during session activation. When the FlexVPN server is configured with a query-identity option, the server queries EAP identity, and the user is prompted for both username and password. When the query-identity option is not configured, the user is prompted only for the password. In this instance, the IKE identity is used as the EAP username. The following example illustrates the user prompt for EAP credentials on the FlexVPN client.
Following is the user prompt when the query-identity option is configured on the FlexVPN server.
Enter the command crypto eap credential profile1
crypto eap credentials profile1
Enter the Username for profile profile1: user1
Enter the password for username cisco: password1
Note when using EAP, the username is treated as the IKE identity; in this case, if two devices have the same username and password combination they will not be able to connect to the same VPN headend at the same time. This is because the initial contact tears the first session down when the second session connects using the identical attributes.
Following is the user prompt when the query-identity option is not configured on the FlexVPN server.
Enter the command crypto eap credentials profile1
crypto eap credentials profile1
Enter the password for username <IDi>: password1
Split-DNS
The Split-DNS function allows the FlexVPN client to act as a DNS proxy. The FlexVPN server pushes the domain names for split-DNS using the Cisco proprietary configuration attribute MODECFG_SPLITDNS_NAME.
In a typical scenario the FlexVPN client will have a DNS server configured that is on the service provider network and will act as a proxy. All DNS requests will be sent to this server from hosts on the internal protected network, even if the VPN is not active between the FlexVPN client and server. The split-DNS function enables a dynamic DNS view to be installed on the inside interface on creation of the VPN between the FlexVPN client and FlexVPN server. The inside interfaces are configured in the FlexVPN client profile, using the client inside interface-name command. When the inside interfaces are not configured in the client profile, the DNS view is applied to all interfaces except the tunnel interface and the tunnel source interfaces of all configured profiles. This DNS view will contain domain names and will then be used for requests from devices on the inside interface, which make requests for the specified domain names. The DNS view will take precedence over the default DNS server configured (that is, on the service provider network). When the FlexVPN client tunnel is torn down, the dynamic view is removed from the inside interface, and all DNS requests will be processed by the DNS server on the service provider network. Allowing for certain DNS requests to be processed by the service provider reduces the load on the corporate DNS server.
Figure 10-2 illustrates a scenario where the FlexVPN client acts as a relay for internal clients and sends all DNS requests for any domain to a server on the service provider network because the VPN tunnel to FlexVPN server is down.
After the FlexVPN client establishes a VPN tunnel to the FlexVPN server, a DNS view is installed on the FlexVPN client, and requests for specific DNS domain queries (specified in the DNS view) are sent via the VPN.
Figure 10-3 illustrates split-DNS. The domain-name example.net is used for split-DNS and sent from the FlexVPN server and installed within a DNS view on the FlexVPN client to use the DNS server within the tunnel for domain. The FlexVPN client is acting as a DNS server for clients on the inside network. When these clients make requests that contain the example.net domain, these requests are sent to the DNS server through the tunnel. All other requests are sent to the DNS server on the service provider network. This allows for the clients protected behind the FlexVPN client to use the Internet for all DNS requests apart from the domains local to the company. This saves Internet-bound traffic having to go from the FlexVPN client to the FlexVPN server and then on to the Internet.
Components of Split-DNS
Split-DNS requires the following components to be configured.
The FlexVPN server must have at least one DNS server configured as part of the AAA user or group authorization profile for the client either within the IKEv2 authorization policy for local AAA or on the RADIUS server. Up to two DNS servers can be configured for each IP address family (IPv4/IPv6) with the first acting as the primary and second as the secondary.
Table 10-1 illustrates the methods of configuring the IPv4 DNS server attributes.
Table 10-2 illustrates the methods of configuring the IPv6 DNS server attributes.
The FlexVPN server must be configured with the domains that will need to be proxied by the FlexVPN client. These domains must be configured as part of the AAA user or group authorization profile for the client, either within the IKEv2 authorization policy for local AAA or on the RADIUS server. Up to ten domains can be configured using a separate attribute or command for each.
Table 10-3 illustrates the methods of configuring the split-DNS attribute.
The FlexVPN client must have a default DNS server configured along with a DNS view. Normally the DNS server will reside on the service provider network and the DNS Server pushed via the FlexVPN server will reside behind the FlexVPN tunnel.
The following example shows the relevant configuration on the FlexVPN client and server to enable split-DNS. After enabling DNS name-list debugging using the command debug ip dns name-list and DNS View debugging using the command debug ip dns view, the name list and DNS server can be seen being added to the local DNS view when the VPN become established. This can be verified by viewing the local DNS name list using the command show ip dns name-list, which will show domains received from the FlexVPN server. Before the VPN is established, this list is empty unless manually configured.
Configuration on FlexVPN server:
crypto ikev2 authorization policy default
dns 192.168.10.5 192.168.10.6
split-dns example.net
Configuration on FlexVPN client:
ip dns view default
domain name-server 172.16.10.1
ip dns server
The following example illustrates the verification of a DNS view as it is installed on the FlexVPN client.
The selected debug crypto ikev2 and debug crypto ikev2 client flexvpn output below capture the DNS server and split-DNS attributes received from the FlexVPN server.
Received Packet [From 10.10.10.2:500/To
10.10.10.1:500/VRF i0:f0]
Initiator SPI : F09A4EC10E7723C6 - Responder SPI : C980EE3D55880C04 Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
Config-type: Config-reply
Attrib type: ipv4-dns, length: 4, data: 192.168.10.5
Attrib type: ipv4-dns, length: 4, data: 192.168.10.6
Attrib type: split-dns, length: 18, data: example.net
FlexVPN(flex1 : 80000009) DNS Primary: 192.168.10.5
FlexVPN(flex1 : 80000009) DNS Secondary: 192.168.10.6
FlexVPN(flex1 : 80000009) Split DNS Name: example.net
The debug ip dns name and debug ip dns view output below capture the creation of DNS view on FlexVPN client.
DNS_VIEW: creating view flexvpn-view-flex1
DNS_VIEW: Setting dns forwarder 192.168.10.5 192.168.10.6 in view
flexvpn-view-flex1
DNS_VIEW: Setting domain name-server 192.168.10.5 192.168.10.6 in view
flexvpn-view-flex1
DNS_NAMELIST: adding permit 'EXAMPLE.NET' to name-list 1
The show crypto ikev2 sa detailed command output displays the DNS server IP addresses pushed by the FlexVPN server.
FlexClient#show crypto ikev2 sa detailed
DNS Primary: 192.168.10.5
DNS Secondary: 192.168.10.6
The show crypto ikev2 client flexvpn flex1 detail command output displays the split DNS domains pushed by the FlexVPN server.
FlexClient#show crypto ikev2 client flexvpn flex1 detail
Split DNS:
example.net
The show ip dns name-list command output displays the split-DNS domains installed in the DNS view.
FlexClient#show ip dns name-list
ip dns name-list 1
permit EXAMPLE.NET
Windows Internet Naming Service (WINS)
The FlexVPN server has the ability to push the Windows Internet naming service (WINS), also known as the NetBIOS name service (NBNS), using the IKEv2 configuration exchange, which is then integrated into the DHCP server running on the FlexVPN client. This allows for hosts that gain an IP address by the local DHCP server to have the configured WINS applied.
The FlexVPN server pushes the IPv4 WINS, using the standard IKEv2 configuration attribute INTERNAL_IP4_NBNS. At the time of writing, the FlexVPN server does not support pushing the IPv6 WINS, using INTERNAL_IP6_NBNS attribute.
Table 10-4 illustrates the methods of configuring the IPv4 WINS attribute.
A DHCP server must be configured on the FlexVPN client that allows for DHCP options to be programmatically imported, this is achieved using the import all command within the DHCP server configuration. The WINS attributes can be verified that it has been passed in the IKEv2 exchange, using the command show crypto ikev2 sa detailed. To verify that the DHCP server has been updated can be achieved using the command show ip dhcp import.
The following example details the configuration on a FlexVPN server and FlexVPN client. The WINS server is configured as 10.10.210.10 on the FlexVPN server; this is passed to the FlexVPN client and dynamically updated on the local DHCP server.
Configuration on the FlexVPN server is as follows:
crypto ikev2 authorization policy default
wins 10.10.210.10
Configuration on FlexVPN client:
ip dhcp pool pool1
import all
network 10.10.1.0 255.255.255.0
default-router 10.10.1.1
dns-server 10.10.1.1
crypto ikev2 client flexvpn flex1
peer 1 172.16.10.1
connect manual
client inside Ethernet0/1
client connect Tunnel1
The following example illustrates how the attributes can be verified that they have been updated to the local dynamic DHCP server. Devices that are allocated IP addresses from the DHCP server will have the dynamic attributes applied.
FlexVPNClient#show ip dhcp import
Address Pool Name: pool1
NetBIOS Name Server(s): 10.10.210.10
FlexClient#show crypto ikev2 sa detailed
WINS Primary: 10.10.210.10
Domain Name
The FlexVPN server has the ability to push the default domain name, using the IKEv2 configuration exchange. This attribute is then integrated into the DHCP server running on the FlexVPN client and allows for the host client that gains an IP address by the local DHCP server to have the pushed domain-name applied.
The FlexVPN server pushes the default domain, using the Cisco proprietary IKEv2 configuration attribute MODECFG_DEFDOMAIN.
Table 10-5 illustrates the methods of configuring the default-domain attribute.
A DHCP server must be configured on the FlexVPN client that allows for DHCP options to be programmatically imported. This is achieved using the command import all within the DHCP server configuration. The default domain name can be verified that it has been passed in the IKEv2 exchange, using the command show crypto ikev2 sa detailed. To verify that the DHCP server has been updated can be achieved using the command show ip dhcp import.
The following example details the configuration on a FlexVPN server and FlexVPN client. The default domain of example.net is configured on the FlexVPN server, passed to the FlexVPN client, and dynamically updated on the local DHCP server.
Configuration on the FlexVPN server:
crypto ikev2 authorization policy default
wins 10.10.210.10
def-domain example.net
Configuration on the FlexVPN client:
ip dhcp pool pool1
import all
network 10.10.1.0 255.255.255.0
default-router 10.10.1
dns-server 10.10.1.1
crypto ikev2 client flexvpn flex1
peer 1 203.0.113.224
connect manual
client inside Ethernet0/1
client connect Tunnel1
FlexVPNClient#show ip dhcp import
Address Pool Name: pool1
Domain Name Option: example.net
FlexClient#show crypto ikev2 sa detailed
Default Domain: example.net
FlexVPN Client Profile
The FlexVPN client consists of a number of configuration building blocks that are required to connect to the FlexVPN server. The FlexVPN client profile is the inner workings of the FlexVPN client and defines the following
Which FlexVPN server(s) the client will connect to
The tunnel interface used to connect
The method that the client will use to connect (auto/manual/track)
The source interface used to initiate the tunnel
Backup groups
These attributes are configured within the client profile, which is configured using the command crypto ikev2 client flexvpn profile-name.
The client profile will integrate with the other FlexVPN components to dynamically build a tunnel used to connect to the FlexVPN server, rather than having a statically configured tunnel with the IP address of the FlexVPN server. The FlexVPN client must have the matching cryptographic attributes as the FlexVPN server configured in the IKEv2 proposal. Like any other implementation of FlexVPN, an IKEv2 profile will be used to define the IKEv2 identity, VRF, match peer identity, and so on.
Backup Gateways
Multiple peers can be configured on the FlexVPN client for each FlexVPN server that the client will attempt to connect to, although only one peer will be active at any given time. Peers are ordered in a sequential manner with the lower-sequenced peer having the higher preference. Connections will be attempted to peers in order; if the connection to one peer fails, the next peer will be attempted. Four IKEv2 connections will be attempted, with an incrementing back-off timer between connection attempts. The back-off timer will start at 2 seconds, then double to 4, 8, and then 16 seconds.
The peers are configured in the FlexVPN client profile using the following command.
peer sequence {ipv4-address | ipv6-address | fqdn fqdn-name [dynamic | ipv6]}
[track track-number [up | down]]
Resolution of Fully Qualified Domain Names
If the peer is defined by FQDN, by default this will be resolved to an IP address by DNS when the configuration is applied unless the dynamic keyword is included. If the dynamic keyword is used, the FQDN will be resolved to an IP address using DNS when the tunnel is initiated. This name resolution will be performed only once; as soon as the FQDN is resolved, the corresponding IP address will be added to the configuration. If the configuration is then saved (using the copy run start command), the saved configuration will contain the destination of an IP address and not FQDN.
Reactivating Peers
Should a connection successfully establish to a peer that doesn’t have the highest preference, by default if a more preferential peer should then become available, the connection to the most preferential peer will not be established. This behavior can be changed using the peer reactivate command, which will enable the current connection to terminate and a new connection to be attempted with the more preferred peer.
Backup Gateway List
In addition to the manually configured peers on a FlexVPN client, a FlexVPN server can push a backup gateway list during the session bring up, using IKEv2 configuration exchange, which is a list of additional peers that the client can connect to, should the connection to the server fail. The downloaded list is inserted right after the peer from which the list was downloaded.
The FlexVPN server can push up to 10 backup gateways using the Cisco proprietary IKEv2 configuration attribute MODECFG_BACKUPSERVERS.
Table 10-6 illustrates the methods of configuring the backup-gateway attribute.
The following example illustrates the backup gateway list functionality.
A client is configured with three static peers (A, B, C) in the listed order of priority. For any reason, when the client connects to peer B and a list of three other peers (1, 2, and 3) is downloaded from that peer, the complete ordered gateway list effectively becomes
Peer A (priority 1)
Peer B (priority 2)
Peer B.1 (priority 2.1)
Peer B.2 (priority 2.2)
Peer B.3 (priority 2.3)
Peer C (priority 3)
In this case, the static peer B is defined as the parent peer for the downloaded list. If peer B.1, B.2, or B.3 pushed a new list at connection time, the old downloaded list would be deleted and replaced with the new list, keeping B as a parent peer for the downloaded list.
Tunnel Interface
The FlexVPN client uses a static point-to-point tunnel interface with either GRE or native IPsec encapsulation mode to connect to the FlexVPN server. The tunnel interface used by FlexVPN client is unique in the following ways.
The IP address of the tunnel interface can either be statically configured or be configured to request an IP address from the FlexVPN server using the ip address negotiated command.
The tunnel source and tunnel destination can be dynamically programmed from the FlexVPN client profile, based on the availability of the peer and the source interface which is enabled using tunnel source dynamic and tunnel destination dynamic commands. Note that when using dynamic tunnel source and destination, the currently active tunnel source and destination can be seen in the show crypto ikev2 client flexvpn command output and not in the running configuration.
The tunnel interface is referenced from the client profile, using the command client connect tunnel interface-number. The tunnel destination address is dynamically obtained from the client profile; this IP address is generated from the selected peer statement in the client profile. The tunnel interface must be protected with an IPsec profile referencing the IKEv2 profile, using the command crypto ipsec profile name.
Tunnel Source
The source interface of the tunnel can be configured to be static or dynamic. If the tunnel source will always use the same interface, then the tunnel source can be statically set using the command tunnel source interface|ip-address.
If multiple source interfaces are needed for the client the tunnel interface must be set to dynamic using the command tunnel source dynamic. If the tunnel source is set to dynamic, the tunnel source will be obtained from the client profile. The client profile can be configured with multiple interfaces that can be potentially used as tunnel source, with each interface assigned a unique sequence number and a track object. An interface is considered available only when the track object is in the “up” state. The available interface with the lowest sequence number and with the VRF matching the “tunnel fvrf” is used as tunnel source. If a session is “up” with a given source then, such a source is said to be a “current active source.” Any change in current active source will terminate the active session.
Using a dynamic tunnel source allows for multiple bearers to be used as the transport network. Many customer will use a single device for secure connectivity. This device will have a number of connections to the VPN headend, each using different transport networks of varying quality and cost. Having a dynamic tunnel source allows for the choice of the higher quality or less costly bearer to be used when the VPN headend is reachable over this link. If connectivity to the VPN headend fails, the backup link sources the traffic from a different interface. This allows for costly connections to only be used when required, resulting in savings when backup links are charged, based on the amount of traffic sent.
The following example illustrates the dynamic tunnel source configuration. The current value of the tunnel source can be seen in the show crypto ikev2 client flexvpn command output’s source field as highlighted below. Note that the running configuration does not display the current tunnel source interface.
interface Tunnel10
ip address negotiated
tunnel source dynamic
crypto ikev2 client flexvpn flex2
source 1 Ethernet0/0 track 1
source 2 Ethernet0/1 track 2
client connect Tunnel10
FlexClient#show crypto ikev2 client flexvpn
Profile : flex2
Current state:ACTIVE
Peer : 10.0.0.2
Source : Ethernet0/0
Tunnel Destination
The tunnel destination can be configured to be static or dynamic. If there is a single peer then the tunnel destination can be statically set using the command tunnel destination ip-address.
If multiple peers are available, the tunnel destination can be configured to be dynamically set using the tunnel destination dynamic command. The FlexVPN client profile can be configured with multiple peers, each with a unique sequence number and optionally a track object. The peers with a track object are considered available when the associated track object is in the desired state, and the peers without a track object are considered always available. The client profile dynamically programs the tunnel destination to the peer listed in the client profile that has the least sequence number and is available. The current value of the tunnel destination can be seen in the show crypto ikev2 client flexvpn command output’s peer field as highlighted below. Note that the running configuration does not display the current tunnel destination value. The following example illustrates the dynamic tunnel destination configuration.
crypto ikev2 client flexvpn flex2
peer 1 10.0.0.2 track 1
peer 2 10.0.0.3 track 2 down
client connect Tunnel10
interface Tunnel10
ip address negotiated
tunnel destination dynamic
FlexClient#show crypto ikev2 client flexvpn
Profile : flex2
Current state:ACTIVE
Peer : 10.0.0.2
Tunnel Initiation
The FlexVPN client can initiate the VPN using three modes, this is configured within the client profile using the command connect {auto | manual | track number}.
Automatic Mode
Automatic mode is used to automatically start the FlexVPN tunnel activation. If the FlexVPN client is correctly configured, the IKEv2 exchange will begin. User intervention is not required once this mode is enabled. This is the default mode.
Manual Mode
Manual mode requires a user (or user-configured script) to initiate the FlexVPN tunnel using the crypto ikev2 client flexvpn connect name command in exec mode. Once established, the tunnel can be removed using the clear crypto ikev2 client flexvpn name command in exec mode. This command will only initiate a single attempt to a peer; if the peer in unavailable, then the IKEv2 negotiation will fail, and the next connection attempt will proceed to the next configured peer. However, this connection will not be attempted until the user initiates it.
Track Mode
The FlexVPN client can initiate a connection, depending on the state of a tracked object. The client process integrates to the enhanced object tracking feature and receives notifications when the state of tracked object changes.
The enhanced object tracking feature allows for a tracking of objects, such as:
The line protocol state on an interface
The presence of IP routing that is enabled on an interface
The state on an SLA operation
The presence of a prefix in the routing table
The reachability of an SLA host
Tracking a List of Objects, Using a Boolean Expression
The tracked object can either be in the “up” or “down” state. If the track keyword is set to activate the tunnel when the object is in the “up” state, the client triggers the connection upon receiving a notification that the object is in the “up” state. If the track keyword is set to activate the tunnel when the object is in the “down” state, the client triggers the connection upon receiving the notification that the object is in the “down” state.
The following example shows the connect track command being used to only activate the tunnel should the line protocol on interface Ethernet 0/2 be “up”; if the line protocol is “down,” the tunnel will not activate. Should a FlexVPN client establish a connection to the FlexVPN server and the status of the track event change from “up” to “down,” the tunnel to the FlexVPN server will be brought down.
Define the track object.
track 10 interface Ethernet0/2 line-protocol
Reference the track object from the client profile.
crypto ikev2 client flexvpn flex1
peer 1 203.0.113.225
connect track 10
client inside Ethernet0/1
client connect Tunnel1
The following example shows the track state changing status; in turn, this brings the FlexVPN client up or down, depending on the tracked event.
%TRACKING-5-STATE: 10 interface Et0/2 line-protocol Down->Up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%TRACKING-5-STATE: 10 interface Et0/2 line-protocol Up->Down
%FLEXVPN-6-FLEXVPN_CONNECTION_DOWN: FlexVPN(flex1) Client_public_addr =
209.165.201.1 Server_public_addr = 203.0.113.225
Using tracked events can allow for scenarios with very many options. This is due to the fact that a single track event can track multiple other tracked events using a boolean or threshold outcome for events. Examples include a series of multiple events occurring using the boolean AND operation, along with the occurrence of only one of a number of other events, using the boolean OR operation.
In the following example, a number of track commands are used. First, an IP SLA is created to check whether a device is reachable using the ICMP echo function. Then a track will monitor the status of this IP SLA using track 1. The presence of a prefix (209.165.201.8) in the routing table is tracked using track 2. Track 3 monitors the status of the line protocol of a local interface. Then another tracked object (track 4), is used as a boolean expression to bind all three elements. We actually want to only allow this track to be “up” should both track 1 and 2 be “up” and track 3 be “down.” We achieve this using the boolean NOT command when adding track object 3.
ip sla 1
icmp-echo 203.0.113.225
ip sla schedule 1 life forever start-time now
track 1 ip sla 1
track 2 ip route 209.165.201.8 255.255.255.255 reachability
track 3 interface Ethernet0/2 line-protocol
track 4 list boolean and
object 1
object 2
object 3 not
FlexClient#show track
Track 1
IP SLA 1 state
State is Up
1 change, last change 01:30:49
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
Track-list 4
Track 2
IP route 1 209.165.201.8 255.255.255.255 reachability
Reachability is Up (static)
1 change, last change 00:27:46
First-hop interface is Ethernet0/0
Tracked by:
Track-list 4
Track 3
Interface Ethernet0/2 line-protocol
Line protocol is Down (hw admin-down)
2 changes, last change 00:00:08
Tracked by:
Track-list 4
0
Track 4
List boolean and
Boolean AND is Up
4 changes, last change 00:00:07
object 1 Up
object 2 Up
object 3 not Down
Dial Backup
In scenarios where the FlexVPN client router has multiple WAN connections, the track-based tunnel activation feature can be used to implement the dial backup feature (aka primary and backup tunnels) in the following ways.
A FlexVPN tunnel can be created over each of the WAN interfaces with one tunnel acting as primary and the other as backup. This can be accomplished by having both the tunnels track the same object for tunnel activation with one tunnel tracking the “up” state and the other tracking the “down” state of the common track object.
A FlexVPN tunnel can be created over the one of the WAN interfaces (e.g., Internet) that acts as a backup to another WAN connection (e.g., dial-up connection). This can be accomplished by using track-based tunnel activation on the FlexVPN tunnel tracking the primary connection going down.
Backup Group
Each FlexVPN client profile can be manually assigned to a backup group; if a backup group is not configured, the default backup group of “0” or default is used. A configuration profile can be configured to participate in a backup group with the backup group 1-255 command.
When a FlexVPN client is required to initiate a connection to a peer, it will validate if there are any other FlexVPN client profiles in the same backup group which have established sessions to the same peer. If a connection is established and the client profile is a member of the same backup group, then the connection to the peer will be bypassed and the next peer attempted.
If the same peer is configured in separate profiles with different backup groups configured, there is a possibility that a simultaneous connection will be made to both peers.
In the following example, two FlexVPN client profiles are configured with the same backup group (10). The FlexVPN client profile named “flex1” establishes a connection to peer 172.16.1.1. The FlexVPN client profile named “flex2” fails to establish a connection to the first configured peer (172.16.2.1). After the IKEv2 timeout, the second peer is tried. Because there is already an active connection to this peer using the FlexVPN client profile “flex1” and these are in the same backup group, this peer is skipped, and a connection to the next peer is attempted. The syslog messages were generated after enabling FlexVPN client debugging, using the command debug crypto ikev2 client flexvpn.
crypto ikev2 client flexvpn flex1
peer 1 172.16.1.1
backup group 10
client connect Tunnel1
crypto ikev2 client flexvpn flex2
peer 1 172.16.2.1
peer 2 172.16.1.1
peer 3 172.16.3.1
backup group 10
client connect Tunnel2
FlexVPN(flex2 : 8000000B) Current_state: NEGOTIATING
FlexVPN(flex2 : 8000000B) Current_event: EV_TP_ERROR
FlexVPN(flex2 : 8000000B) Error during negotiation
initiating auto reconnect timer
FlexVPN(flex2 : 8000000B) Current_state: NEGOTIATING
FlexVPN(flex2 : 8000000B) Current_event: EV_DISCONNECT
%FLEXVPN-6-FLEXVPN_CONNECTION_DOWN: FlexVPN(flex2) Client_public_addr = 172.16.4.1
Server_public_addr = 172.16.2.1
FlexVPN(flex2 : 0) Connection being terminated with peer 198.51.100.133
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to down
FlexVPN(flex2 : 0) advanced to next peer 172.16.1.1
FlexVPN(flex2 : 0) Current_state: CONNECT_REQUIRED
FlexVPN(flex2 : 0) Current_event: EV_CONNECT
FlexVPN(flex2 : 0) Current_state: CONNECT_REQUIRED
FlexVPN(flex2 : 0) Current_event: EV_SET_PEER
FlexVPN(flex2 : 0) Validating peer 172.16.1.1
FlexVPN(flex2 : 0) Cannot connect to peer 172.16.1.1 since FlexVPN (flex1) is
already connected
FlexVPN(flex2 : 0) Validating peer 172.16.3.1
FlexVPN(flex2 : 0) Ready to connect to peer 172.16.3.1
FlexVPN(flex2 : 0) Current peer set to 172.16.3.1
Network Address Translation
Although not specifically a FlexVPN client feature, Network Address Translation (NAT) requires mentioning because it goes hand-in-hand with the FlexVPN client feature. The FlexVPN client supports two scenarios where NAT can be used.
If the FlexVPN client is to be used to protect devices on an “inside” network, which uses non-routable (RFC 1918) IP addresses, and the FlexVPN client is to provide Internet services to these devices, then NAT can be used to allow the devices to be translated to an Internet-routable IP address when passing through the router.
If the FlexVPN client is to be used to protect devices on an “inside” network that uses IP addresses that are not in the routing table of the FlexVPN server, then NAT can be used to translate IP addresses to the IP address of the tunnel interface when traffic is sent via the point-to-point tunnel between the client and server.
The following example illustrates the configuration on a FlexVPN client that allows clients on the inside network that gain their address via DHCP to be port address translated (PAT’d) to the IP address that is assigned to the tunnel interface.
ip dhcp pool pool1
network 172.16.1.0 255.255.255.0
interface Tunnel1
ip address negotiated
ip nat outside
ip virtual-reassembly in
tunnel source Ethernet0/0
tunnel destination dynamic
tunnel protection ipsec profile default
interface Ethernet0/1
ip address 172.16.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
access-list 1 permit 172.16.1.0 0.0.0.255
ip nat inside source list 1 interface Tunnel1 overload
FlexClient#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.1:6 172.16.1.2:6 192.168.2.1:6 192.168.2.1:6
tcp 192.168.1.1:22079 172.16.1.2:22079 192.168.2.1:23 192.168.2.1:23
The following example illustrates NAT configuration required to translate the enterprise traffic to the server-assigned IP address and split tunnel Internet-bound traffic to a globally routable IP address. The ip nat outside command is configured on tunnel and outbound interfaces and route maps are configured to allow for NAT rules based on the NAT outside interface.
interface Tunnel 0
description FlexVPN client tunnel interface
ip address negotiated
ip nat outside
interface Ethernet 0/0
description WAN-interface
ip nat outside
interface Ethernet 1/0
description LAN-interface
ip nat inside
route-map internet-route permit 1
match interface Ethernet 0/0
route-map flexvpn-route permit 1
match interface Tunnel 0
ip nat inside source route-map crypto-route interface Tunnel0 overload
ip nat inside source route-map internet-route interface Ethernet0/0 overload
Design Considerations
Use of Public Key Infrastructure and Pre-Shared Keys
Although implementing a PKI is preferred over using pre-shared-keys, the use of implementing both pre-shared key and certificate authentication can work well when deploying a FlexVPN client solution. The FlexVPN server(s) can be enrolled into a PKI, while all clients can be configured with a trustpoint containing the PKI used on the FlexVPN server. The client will authenticate the server using the certificate of the server to ensure authentication, and the server will authenticate the client using a pre-shared key. By implementing a RADIUS server containing the pre-shared keys for all clients and allowing the server to use RADIUS to obtain the pre-shared keys for clients, authentication using pre-shared keys for clients can be easily managed from a central location.
The Power of Tracking
The following scenario is where track mode was a perfect fit. A solution was required for a team of mobile engineers that required VPN access over a 3G network. The engineers only wanted to use the VPN when they had their diagnostic IP device connected to the portable router because there was a cost involved when using the 3G network. Because the inside interface would be in the “up” state when the diagnostic device was powered on, a track was used to monitor when the inside interface was in the “up” state and then linked to the FlexVPN client. The VPN would then be initiated only when the diagnostic IP device was connected.
Tracked Object Based on Embedded Event Manager
Embedded event manager (EEM) is a distributed and customized approach to event detection and recovery offered directly in Cisco IOS and IOS-XE devices. EEM offers the ability to monitor events and take informational, corrective, or any desired EEM action when the monitored events occur or when a threshold is reached. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs.
Although EEM does not directly influence the creation of FlexVPN client tunnels, EEM events can be used to influence the status of tracked objects allowing for FlexVPN client tunnels to be initiated, depending on the status of a number of complex events.
A customer approached Cisco Advanced Services to assist in the migration of a VPN solution where routers with multiple WAN interfaces (one having a private, RFC 1918 IP address, and the other having an Internet routable IP address) were to be replaced by a router model with a single WAN interface.
When using the router with two WAN interfaces, the customer had multiple tunnel interfaces configured, with each tunnel having the source of each WAN interface, but the new router model only allowed them to connect to one service provider network at a time. This configuration led to a tunnel interface that was connected when the physical WAN interface was active. The customer needed a solution where, if the WAN interface was connected to a private network (and gained a RFC 1918 IP address), a tunnel would be initiated to a VPN headend on the private network. If the IP address on the WAN interface was not a RFC 1918 address, then the tunnel would initiate to a headend on the Internet. To achieve this, an EEM script was developed to detect the presence of a RFC 1918 IP address on the WAN interface; if this occurred, then a tracked object (track 1) would be set to “up.” Another tracked object (track 2) would be set as the inverse for track 1. A second EEM script was written to detect if the WAN interface went down, this would set track 1 to “down.” The FlexVPN client profile would use the peer on the private network which would use track 1, while the peer on the Internet would use track 2. The following example illustrates the configuration and EEM script used to accomplish this.
track 1 stub-object
track 2 list boolean and
object 1 not
event manager applet intDown
event syslog pattern "Interface Ethernet0/0, changed state to down"
action 1 track set 1 state down
event manager applet getIP
event syslog pattern "Interface Ethernet0/0, changed state to up"
action 1.0 cli command "enable"
action 1.1 cli command "show int e0/0 | inc address is [0-9.]+"
action 2.0 regexp "address is ([0-9.]+)" "$_cli_result" match ip
action 2.1 regexp "(^[0-9]+).([0-9]+)" "$ip" match first second
action 3.0 if $first eq "10"
action 3.1 syslog msg "This is a RFC 1918 address $ip"
action 3.2 track set 1 state up
action 3.3 end
action 4.0 if $first eq "192"
action 4.1 if $second eq "168"
action 4.2 syslog msg "This is a RFC 1918 address $ip"
action 4.3 track set 1 state up
action 4.5 end
action 4.6 end
action 5.0 if $first eq "172"
action 5.1 if $second ge "16"
action 5.2 if $second le "31"
action 5.3 syslog msg "This is a RFC 1918 address $ip"
action 5.4 track set 1 state up
action 5.5 end
action 5.6 end
action 5.7 end
crypto ikev2 client flexvpn flex1
peer 1 172.16.1.3 track 1
peer 2 192.168.1.2 track 2
client connect Tunnel1
Troubleshooting FlexVPN Client
When deploying the FlexVPN client, there are a number of tools that can be used, which are specific to FlexVPN client.
Useful Show Commands
The command show crypto ikev2 client flexvpn displays information about the configured client profiles, the status of each profile, and if connected, downloaded attributes. A specific client profile can be shown by including the name of the profile, using the command show crypto ikev2 client flexvpn name.
The following example displays information about the configured client profiles, the first profile (flex_client_profile_1) is active and has an allocated IP address. The second profile (flex_client_profile_2) is configured to be connected manually; this connection has not been initiated, which can be seen from the current state being CONNECT_REQUIRED.
FlexClient#show crypto ikev2 client flexvpn
Profile : flex_client_profile_1
Current state:ACTIVE
Peer : 203.0.113.225
Source : Ethernet0/0
ivrf : IP DEFAULT
fvrf : IP DEFAULT
Backup group: Default
Tunnel interface : Tunnel1
Assigned IP address: 10.0.0.2
Profile : flex_client_profile_2
Current state:CONNECT_REQUIRED
Backup group: Default
Tunnel interface : Tunnel2
The following lists the attributes displayed by the command show crypto ikev2 client flexvpn.
FlexVPN profile name
Current active peer
Current active source
Backup group
Tunnel interface
Peers
Assigned IP address
Source interface
Current state
The following example illustrates the show crypto ikev2 sa detailed command. This command will display the attributes pushed by FlexVPN server to the client.
FlexClient#show crypto ikev2 sa detailed
DNS Primary: 192.168.10.5
DNS Secondary: 192.168.10.6
WINS Primary: 10.10.210.10
Default Domain: example.net
The show track command can be used to verify if a tracked event is in the “up” or “down” state; this can be useful should a FlexVPN client session be in tracked mode.
The following example shows two configured track commands and the verification that these are in the desired state. The presence of FlexVPN within the “Tracked by” indicates that this is used by a FlexVPN client profile.
FlexClient#show track
Track 1
Stub-object
State is Up
10 changes, last change 02:23:21, by EEM
Tracked by:
Track List 2
FlexVPN 0
Track 2
List boolean and
Boolean AND is Down
11 changes, last change 02:23:20
object 1 not Up
Tracked by:
FlexVPN 0
Debugging FlexVPN Client
The command debug crypto ikev2 client flexvpn will enable debugging messages that relate to the operation of the FlexVPN client and how it interacts with other processes. The logging messages will display events and give a view of how the client profile calls other processes, such as the tunnel interface, and how the peer is selected. There are no specific details displayed in the logging messages for attributes passed using mode-config from the FlexVPN server. The output from the logging messages generated is sparse compared to the output generated by the debug crypto ikev2 command, and for this reason, this command can be handy in diagnosing client connections from a high level.
To enable viewing of the attributes passed in the IKEv2 exchange, the command debug crypto ikev2 can be used to enable debugging. Additionally the command debug crypto ikev2 packet or debug crypto ikev2 packet hexdump can be used for more detailed output.
The following example details the partial output from a FlexVPN client having debug crypto ikev2 packet hexdump enabled
VID Next payload: VID, reserved: 0x0, length: 23
43 49 53 43 4F 2D 44 45 4C 45 54 45 2D 52 45 41
53 4F 4E
VID Next payload: NOTIFY, reserved: 0x0, length: 21
46 4C 45 58 56 50 4E 2D 53 55 50 50 4F 52 54 45
44
The above output shows the Vendor ID payload containing the hexadecimal representation of the strings CISCO-DELETE-REASON and FLEXVPN-SUPPORTED, indicating that FlexVPN client is in use.
Clearing IKEv2 FlexVPN Client Sessions
The command clear crypto ikev2 client flexvpn will clear all the current FlexVPN client connections. Specific profiles can be cleared by using the clear crypto ikev2 client flexvpn name command, including the name of the profile. When clearing the client connection for a profile that uses a manual connection (connect manual), the IKEv2 SA will be cleared, bringing down the IPsec Security Association. When clearing the client connection for a profile that uses an auto connection (connect auto) or tracked connection (connect track), the IPsec Security Association will be recreated, that is a CREATE_CHILD_SA exchange will occur, keeping the current IKEv2 SA.
To clear the IKEv2 SA for the peer, use the command clear crypto ikev2 sa remote [ipv4 address | ipv6 address].
Summary
FlexVPN client allows for remote working for small-office, home-office, and mobile workers, such as salespeople. Using the power of mode-config, attributes can be passed in the IKEv2 exchange that allows configuration on the FlexVPN client that integrates with local features. The FlexVPN client is designed to provide secure communications from the remote location to the FlexVPN server; the client will provide services such as DHCP and DNS to other devices connected to the router. The attributes passed from the FlexVPN server will integrate with these local services dynamically, allowing local devices to receive configuration from the FlexVPN client via DHCP and DNS that was passed from the FlexVPN server.
The benefits are that FlexVPN client can be used in virtually any scenario. The features implemented using FlexVPN client are not just for mobile workers, they can be implement whenever FlexVPN is used.