Initial status of the branch office network
Take a look at example of connecting an office to a DMVPN cloud, where two Internet access channels from different Internet service providers are used: one of them provides access via a wired connection and the other via a stick modem.
Figure 9. Diagram showing how to connect a branch office router to Internet (with backup connection via modem) via the networks of two Internet service providers
Within this DMVPN scheme, two GRE tunnels are set up on the Spoke node: one to the first DMVPN Hub, and another one to the second. The Spoke node has IP connectivity via two independent Internet providers; the transport of the first Internet provider is used to connect to the first DMVPN Hub , using the uplink as a “wired” connection to the network, while the second ISP's transport is used to connect to the second DMVPN Hub using a stick modem. In this guide, a Huawei E8372 stick modem is used.
The branch office router connects to two ISPs, each of which provides a channel with a white statically assigned IP address. For ease of configuration, assign names to both devices in this diagram.
Organizing the local network segment of a branch office
As part of this guide, examine a simple access switch configuration for connecting the equipment of a branch office to a border router. The parameters of the office's local network are described in Table 24.
Table 24. Local network parameters for branch office No. 5.
| Purpose | VLAN | Subnet |
|---|---|---|
| Local area network of the branch office No. 5 | 100 | 192.168.15.0/24 |
Move on to configuring the switch. The client ports must be configured in general mode. The required VLAN ID is assigned to untagged traffic.
Configure the physical interface facing the router as a trunk port for the required VLAN ID
Move on to configuring the border router. Add a subinterface for processing tagged traffic with the appropriate VLAN ID:
Add a security zone for the subinterface and ensure that incoming ICMP traffic from this security zone is accepted:
Connecting to an Internet service provider No. 1 using wired connection with static addressing
Take a look at the process of connecting to the Internet using the data provided by ISP No. 1 for configuring static addressing on the interface. The parameters for connecting to the Internet provider are described in Table 25.
Table 25. Data from ISP No. 1 for configuring static IP addressing on the border router of branch office No. 5
| Parameter | Value |
|---|---|
| Router IP | 203.11.1.2 |
| Network mask | 255.255.255.0 |
| Gateway IP | 203.11.1.1 |
In this example, both ISP No. 1 and ISP No. 2 provide public (white) IP addresses for static addressing configuration. In cases where an Internet service provider provides a private (gray) IP address for configuration with subsequent NAT conversion to public IP addressing, the configuration will be similar.
Move on to configuring the network interface and static routing. Separate the interface using VRF – the Front-Door VRF scheme will be configured later.
A connection scheme in which the transport network for a certain virtual network is moved to a separate network namespace is called Front-Door VRF. This scheme of organizing transport for a virtual network offers the following advantages:
- the ability to use the default route in both virtual and transport networks;
- no intersection of routing information between the transport and virtual networks;
- an additional level of security for the virtual network, since traffic from it cannot enter the transport network without configured encapsulation into a tunnel.
Configure a separate security zone for this network interface and allow ICMP traffic incoming to the router from this security zone:
Connecting to an Internet service provider No. 2 using static addressing
Take a look at the process of connecting to the Internet using the data provided by ISP No. 2 for configuring static addressing on the interface. The parameters for connecting to the Internet provider are described in Table 26.
Table 26. Data from ISP No. 2 for configuring static IP addressing on the border router of branch office No. 5
| Parameter | Value |
|---|---|
| Router IP | 203.11.0.2 |
| Network mask | 255.255.255.0 |
| Gateway IP | 203.11.0.1 |
Move on to configuring the stick modem and static routing. Separate the interface using VRF – the Front-Door VRF scheme will be configured later.
The first step in configuring a modem connection is to connect the modem to the border router and wait for the modem manufacturer and slot number where the modem is connected to be detected. This information can be viewed using the show cellular status modem command. If there is no configuration for modems, the modem status will be disabled/Down.
The second step is to configure the stick modem interface itself. Proceed as follows:
When configuring the modem, a profile must be created specifying the APN of the operator to which the connection is made, and the USB port ID of the modem obtained in the first step using the show cellular status modem command must be specified. Additionally, the default route through the modem interface must be set to enable Internet access.
Configure a separate security zone for the network interface connected to ISP No. 2 and allow ICMP traffic incoming to the border router from this security zone:
Configuring IKEv2 and IPsec tunneling on DMVPN Spoke
Configuring IPsec for the future DMVPN cloud is an important part of this guide. Correct IPsec configuration ensures the privacy and security of traffic between offices. IKE and IPsec parameters shown in Table 27 will be used in further configuration.
Table 27. IKE and IPsec parameters used to configure IPsec tunneling on the DMVPN Spoke router of branch office No. 5.
| RT-OFFICE-5 | ||
|---|---|---|
| IKE parameters | Encryption algorithm | AES-256 |
| Hashing algorithm | SHA2-256 | |
| Diffie-Hellman group | 19 | |
| IKE session lifetime in seconds | 86400 | |
| IKE session identifier | spoke5.company.loc | |
| Interval for sending DPD messages | 40 | |
| Total timeout for DPD message response | 160 | |
| Action when DPD timeout occurs | Terminating the IKE session | |
| IPsec parameters | Encryption algorithm | AES-256 |
| Hashing algorithm | SHA2-256 | |
| Diffie-Hellman group for a PFS mechanism | 19 | |
| IPsec session lifetime in seconds | 28800 | |
| IPsec session lifetime in kilobytes | 4608000 | |
| Early reauthentication interval for IKE session/Early rekeying interval for IPsec session in seconds | 3600 | |
| Threshold value for early reauthentication interval of IKE session/Threshold value for early rekeying of IPsec session in kilobytes | 86400 | |
IPsec configuration begins with configuring encryption algorithm sets for the IKE protocol:
Create an IKE authentication keyring. Since domain names are going to be used as IPsec neighbor identifiers in further configuration, domain names will also be used in the keyring:
Create an IKE policy. It includes encryption algorithm sets, authentication method selection and lifetime of IKE session (Phase 1):
Create a set of IKE gateways.
Due to the specifics of IPsec configuration in the DMVPN scheme on ESR service routers, multiple IPsec VPN policies must be created on routers acting as DMVPN Spokes: one for connecting to other DMVPN Spokes and one for each configured DMVPN Hub.
The number of possible settings in IKE gateway is quite large, so focus on the most important configuration items:
- To use IKE version 2, the "version v2-only" command is required, otherwise the tunnel will use IKE version 1.
- Support for MOBIKE protocol must be disabled, as in the DMVPN scheme it can lead to errors in creating tunnels between DMVPN Hub and DMVPN Spoke.
- If the gateway is bound to an interface using the "local interface" command, it is possible to bind the local network to the address on this interface with the "local network dynamic" command.
- In the DMVPN scheme, only GRE traffic goes through IPsec tunnels, so it is correct to specify the "protocol gre" key in the "local network" and "remote network" commands.
Configure the policy for duplicate IKE sessions to replace existing IKE sessions when duplicates occur:
Create a set of encryption algorithms specifically for the IPsec tunnel:
Next create an IPsec policy. It includes sets of encryption algorithms and the lifetime of the IPsec session directly responsible for encrypting user traffic:
Configured IKE and IPsec settings can be combined into general VPN profiles. As with IKE gateways, four IPsec VPN profiles will be created. For IPsec VPN profiles used on GRE tunnels in the DMVPN scheme, it is necessary to enable transport mode:
Allow traffic associated with IPsec tunnels to pass through. To do this, first describe the port profiles for the IKE protocol and the encrypted traffic of the IKE and ESP protocols packaged in UDP:
Allow incoming IPsec tunnel traffic for each ISP (Firewall):
User traffic is encapsulated in the ESP protocol and if there is NAT between IPsec neighbors, ESP protocol messages are in turn encapsulated in the UDP protocol, port 4500.
Since tunnels between DMVPN Spokes can be established without NAT between them, allow ESP packets to pass through using a separate rule.
Configuring mGRE tunnels on DMVPN Spoke
Configure GRE tunnels in multipoint mode with NHRP protocol support on DMVPN Spoke. Since two DMVPN Hubs are deployed in the central office with addresses from two different ISPs, the connection to them will be made using two separate mGRE tunnels. The difference from the DMVPN Spoke configuration with a connection to a single Internet service provider is that the NBMA address for each GRE tunnel will differ depending on the IP address of the interface to that Internet service provider. The main parameters of the GRE tunnels for connecting to both DMVPN Hubs are shown in Table 28.
Table 28. Parameters of GRE tunnels on the DMVPN Spoke router of branch office No. 5
| DMVPN Hub | DMVPN Cloud | GRE tunnel number | DMVPN Spoke tunnel addressing | DMVPN Hub tunnel address | DMVPN Hub NBMA address | GRE tunnel key | Lifetime of NHRP entries in seconds |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-CORE Cloud | 11 | 172.16.1.15/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-MODEM Cloud | 12 | 172.16.2.15/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
First, change the general settings for GRE tunnels on each DMVPN Hub. These settings include:
- multipoint mode;
- key value;
- TTL value;
- MTU size;
- adjust-mss TCP value;
- tunnel IP address;
- interface from which the GRE tunnel will be established;
- transport VRF name.
From the perspective of the NHRP protocol, DMVPN Spoke routers act as NHRP clients, which, after registering in the DMVPN cloud on one or more DMVPN Hubs, can request information about other members of the DMVPN cloud from them. In this regard, for DMVPN Spoke to work correctly, it is necessary to describe the NHRP protocol settings for connecting to both DMVPN Hubs.
To correctly establish Spoke-to-Spoke tunnels, where routing directs all traffic to the DMVPN Hub, enable the "ip nhrp shortcut" option, which activates the DMVPN Spoke's response to special NHRP "Traffic Indication" messages that the DMVPN Hub will send in response to packets destined for another DMVPN Spoke. Processing such a message will result in the construction of a Spoke-to-Spoke tunnel and traffic between DMVPN Spokes will flow directly, bypassing the DMVPN Hub.
This scheme for organizing routing and establishing Spoke-to-Spoke tunnels in DMVPN clouds is commonly referred to as DMVPN Phase 3.
It should be noted that the recreation of Spoke-to-Spoke tunnels is initiated only after the specified holding-time parameter has expired. Thus, in the event of an Internet provider failure and, accordingly, a loss of connection to the DMVPN Hub, the Spoke-to-Spoke tunnel will be reconfigured to the backup Internet provider upon expiration of the Expire time for the corresponding Spoke-to-Spoke tunnel.
Due to the nature of traffic decapsulation from IPsec tunnels operating in transport encapsulation mode, decrypted traffic ends up on the same network interface that terminates the IPsec tunnel. Therefore, the firewall rules on the DMVPN Spoke must allow not only encrypted IPsec packets, but also GRE packets that arrive at the interface after decryption.
To filter traffic within the DMVPN cloud, a separate security zone must be created and assigned to GRE tunnels. Allow incoming ICMP traffic to pass through this zone:
Configuring routing for DMVPN cloud operation at the central office
Configure BGP neighbors facing the DMVPN Hub:
Since DMVPN Spoke and DMVPN Hub are located in different autonomous systems, route information will not be advertised by default. Create a route map that allows sending routes to local network on DMVPN Hub. When default routes are distributed, they are announced with different metrics, which allows for the selection of a priority direction. If the second Internet provider, and therefore the second hub, is unavailable, routing is switched using the BFD protocol mechanism.
Specify the created route map for the IPv4 route family in the created BGP neighbors. Also, add the local network to the advertised routes:
Enable BFD support for created BGP neighbors. Increase BFD timers, taking into account the convergence speed of IPsec and mGRE tunnels:
Allow incoming BGP and BFD traffic to pass through the security zone configured on GRE tunnels:
Configuring Zone-Based Firewall for local area network
Since the DMVPN cloud that has now been created allows traffic of local users at the branch office to exit via the central office's Internet gateway, additional firewall settings are required.
Allow transit traffic from the local network to pass to the DMVPN cloud:
At this point, configuration of DMVPN with a backup channel in the branch office can be considered complete.