Initial configuration of equipment in central office
As an example of central office infrastructure, examine the topology from the "Network design in large office" design guide. Within the framework of this design document, the office network was organized with local users accessing the Internet via one of two available Internet providers. The diagram also shows a demilitarized zone segment for hosting services with the ability to publish them on the Internet using Destination or Static NAT technology.
Figure 2. Central office network diagram from the "Network design in large office" design guide
The equipment configurations in this diagram are shown below:
Before configuring basic settings for the aggregation layer switches (in the proposed diagram), it is necessary to configure stacking.
After configuring stacking settings, the device must be rebooted for the configuration to take effect. It is recommended to start rebooting from unit 1.
Before configuring basic settings for the DMZ switches (in the proposed diagram), it is necessary to configure stacking.
After configuring stacking settings, the device must be rebooted for the configuration to take effect. It is recommended to start rebooting from unit 1.
DMVPN Hub layout in the demilitarized segment of the central office network
Deploy routers acting as DMVPN Hubs in the DMZ segment of the central office network. They will terminate IPsec and GRE tunnels from remote DMVPN Spoke and route traffic to the central office's Internet gateways.
It is recommended to split the DMVPN Hub and corporate Internet gateway functions between different routers due to the increased load on the control plane of the router that terminates multiple DMVPN tunnels.
Thus, the DMVPN Hub layout in the central office will look like this:
Figure 3. DMVPN Hub layout in the DMZ segment of the central office network
Connect both DMVPN Hubs to the DMZ segment switch stack using LAG technology with LACP support enabled. Since the DMZ segment switches are stacked, LAG created on different switches will be perceived by the ESR router as a single aggregated channel.
First, name DMVPN Hub routers:
Configure aggregated interfaces on DMVPN Hub side:
Similarly, configure aggregated interfaces in the DMZ segment switch stack:
Organizing DMVPN Hub access to the central office ISP network using Static NAT
DMVPN Hubs must be accessible for connection via the Internet for DMVPN Spokes, i.e. they must either function on public addresses provided by an Internet service provider, or access to the public network must be provided via an Internet gateway using Static NAT. The second option will be coverered in this guide.
To organize DMVPN Hub access to the Internet, establish network connectivity between DMVPN Hub and the Internet gateways of the central office. To do this, extend a VLAN for each ISP through the already existing L2 segment and add subinterfaces on the aggregated channels of Internet gateways and DMVPN Hub facing the core switches and DMZ, respectively. The network parameters shown in Table 3 will be used for configuration.
Table 3. Parameters of local networks used for DMVPN Hub access to public networks of Internet service providers of the central office
| Internet Service Provider | VLAN | Subnet |
|---|---|---|
| ISP-1 | 210 | 10.0.0.0/30 |
| ISP-2 | 220 | 10.0.0.8/30 |
First, add VLANs of the subnets to each ISP to core and DMZ switches:
Create subinterfaces on aggregated Internet gateway channels leading to core switches:
Do the same on the DMVPN Hub side, but move the created subinterface to a separate VRF.
A connection scheme in which the transport network for a virtual network is moved to a separate network namespace is called Front-Door VRF. This transport organization scheme for a virtual network offers the following advantages:
- the ability to use the default route in both the virtual network and the transport network;
- 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.
Create a separate security zone for these networks on the Internet gateways and DMVPN Hub and add the previously created subinterfaces of the aggregated channels to it. Allow incoming ICMP traffic incoming to the router from this security zone:
Add another public address from the pool assigned by each provider to the existing IP address profile used for ARP Proxy functionality on Internet gateways:
Add a new IP address profile, in which specify the DMVPN Hub address in the local network of the central office.
For Static NAT to work, the size of the subnet to which Static NAT is applied must match the size of the subnet specified in the NAT rules. Therefore, only one entry should be specified in the IP address profile created for further use in the Static NAT rule and only using the “ip prefix” command.
Configure a Static NAT rule in the existing Source NAT rule set:
And allow transit ICMP traffic to pass from the global network to the DMVPN Hub and vice versa:
Connecting DMVPN Hub to the local network of the central office
To route traffic between the central office Internet gateways and the DMVPN Hub, add a separate subnet with the parameters described in Table 4.
Table 4. Parameters of the local network used for DMVPN Hub access to the local network of the central office
| Purpose | VLAN | Subnet |
|---|---|---|
| Subnet for IP connectivity between DMVPN Hub and Internet gateways | 300 | 10.0.0.16/29 |
Add the VLAN of the created network to the core switches and DMZ segment:
Create the corresponding subinterfaces on the aggregated channels:
Create a separate security zone for these networks on the Internet gateways and DMVPN Hub and add the previously created subinterfaces of the aggregated channels to it. Allow ICMP traffic incoming to the router from this security zone:
Configuring IKEv2 and IPsec tunneling on DMVPN Hub
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. For further configuration, use the IKE and IPsec parameters shown in Table 5.
Table 5. IKE and IPsec parameters used to configure IPsec tunneling on DMVPN Hub routers
| RT-HUB-1 | RT-HUB-2 | ||
|---|---|---|---|
| IKE parameters | Encryption algorithm | AES-256 | AES-256 |
| Hashing algorithm | SHA2-256 | SHA2-256 | |
| Diffie-Hellman group | 19 | 19 | |
| IKE session lifetime in seconds | 86400 | 86400 | |
| IKE session identifier | hub1.company.loc | hub2.company.loc | |
| Interval for sending DPD messages | 40 | 40 | |
| Total timeout for waiting for a response to a DPD message | 160 | 160 | |
| Action when DPD times out | Closing an IKE session | Closing an IKE session | |
| IPsec parameters | Encryption algorithm | AES-256 | AES-256 |
| Hashing algorithm | SHA2-256 | SHA2-256 | |
| Diffie-Hellman group for PFS mechanism | 19 | 19 | |
| IPsec session lifetime in seconds | 28800 | 28800 | |
| IPsec session lifetime in kilobytes | 4608000 | 4608000 | |
| Early reauthentication interval for IKE sessions/Early rekeying interval for IPsec sessions in seconds | 3600 | 3600 | |
| Threshold value of IKE sessions reauthentication/Threshold value of IPsec sessions early rekeying in kilobytes | 86400 | 86400 | |
IPsec configuration begins with configuring cryptographic algorithm sets for the IKE protocol:
Next, create an IKE authentication keyring. Since domain names are going to be used as IPsec neighbor identifiers in further configuration, the domain names will also be used in the keyring:
Create an IKE policy. It includes sets of encryption algorithms, authentication method selection and IKE session lifetime:
Create an IKE cryptographic gateway.
- To use IKE version 2, the "version v2-only" command is required, otherwise the tunnel will use IKE version 1.
- MOBIKE protocol support must be disabled, as in the DMVPN scheme it can lead to errors in building tunnels between DMVPN Hub and DMVPN Spoke.
- If the crypto gateway is bound to the interface with 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 is placed in 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 – when duplicates occur, existing IKE sessions will be replaced:
Create a set of cryptographic algorithms specifically for the IPsec tunnel:
Next, create an IPsec policy. It includes sets of encryption algorithms and the lifetime of the IPsec session, which is directly responsible for encrypting user traffic. Unlike an IKE session, the lifetime of an IPsec session can be specified in seconds or in terms of the amount of user traffic that has passed through the tunnel. Configure both options:
Finally, all collected IKE and IPsec settings can be combined into a single VPN profile. For IPsec VPN profiles used on GRE tunnels in a DMVPN scheme, it is mandatory to enable transport mode:
Allow traffic associated with IPsec tunnels to pass through the central office network. To do this, first describe the port profiles for the IKE protocol and the encrypted traffic of the IKE and ESP protocols encapsulated in UDP:
On Internet gateways, allow IPsec tunnel traffic to pass through from interfaces to Internet providers to the DMVPN Hub:
In turn, on the DMVPN Hub, allow the same traffic, but as an incoming one:
Configuring mGRE tunnels on DMVPN Hub
Configure GRE tunnels in multipoint mode with NHRP protocol support on the DMVPN Hub. The main parameters of GRE tunnels for both DMVPN Hubs are shown in Table 6.
Table 6. Parameters of GRE tunnels on DMVPN Hub routers
| Hostname | DMVPN Cloud | GRE tunnel number | Tunnel address | GRE tunnel key | NHRP record lifetime, seconds |
|---|---|---|---|---|---|
| RT-HUB-1 | ISP-1 Cloud | 10 | 172.16.1.1/24 | 1000 | 600 |
| RT-HUB-2 | ISP-2 Cloud | 10 | 172.16.2.1/24 | 2000 | 600 |
First, configure the general settings for the GRE tunnel on each DMVPN Hub. These settings include:
- multipoint mode;
- key value;
- TTL value;
- MTU size;
- TCP adjust-mss value;
- tunnel IP address;
- interface from which the GRE tunnel will be established;
- transport VRF name.
From the perspective of the NHRP protocol, DMVPN Hub routers act as NHRP servers that register new DMVPN cloud members and report the availability of DMVPN cloud members via their external NBMA addresses. In this regard, most of the NHRP protocol settings will be related to requests incoming to the DMVPN Hub.
To correctly establish Spoke-to-Spoke tunnels, where all traffic is routed to the DMVPN Hub, enable the "ip nhrp redirect" option, which will enable the DMVPN Hub to track suboptimal traffic flow between DMVPN Spokes and send a special NHRP "Traffic Indication" message to the DMVPN Spoke whose traffic could go directly to another DMVPN Spoke, bypassing the DMVPN Hub.
This scheme for organizing routing and building Spoke-to-Spoke tunnels in DMVPN clouds is commonly referred to as the third phase of DMVPN.
Due to the nature of decapsulation of traffic from IPsec tunnels operating in transport encapsulation mode, traffic after decryption goes to the same network interface that terminates the IPsec tunnel. In this regard, the firewall rules on the DMVPN Hub must allow not only encrypted IPsec packets, but also GRE packets that arrive at the interface after decryption.
To filter traffic inside the DMVPN cloud, create a separate security zone and assign it to the GRE tunnel. Allow incoming ICMP traffic to pass through this zone:
Configuring routing for DMVPN cloud operation at the central office
Use BGP as the dynamic routing protocol for the DMVPN layout. Its capabilities will provide all the necessary functionality in the current layout, a small configuration size and, in combination with the BFD protocol, rapid detection of connectivity failures between BGP neighbors and prompt network topology reconfiguration.
The membership diagram of configurable routers in autonomous systems is shown in Figure 4:
Figure 4. Logical diagram of router membership in autonomous systems
Begin the configuration with DMVPN Hub. For incoming BGP connections from DMVPN Spoke, configure dynamic BGP neighbors. In this case, only the default route traffic will be sent to DMVPN Spoke, so all DMVPN cloud traffic will pass through 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 the default route to DMVPN Spoke.
In order to assign RT-HUB-1 the role of the main DMVPN Hub for processing traffic in the DMVPN cloud, increase the BGP protocol metric value in its route map. This will give the DMVPN Spoke a higher priority for the default route in its direction.
Specify the created route map for the IPv4 route family in the existing peer group:
Enable BFD support for created BGP neighbors. Take into account the convergence speed of IPsec and mGRE tunnels and increase BFD timers:
Allow incoming BGP and BFD traffic to pass through the security zone configured on GRE tunnels:
Also, set up BGP neighbors for the central office's Internet gateways, but only static ones. Since the connection settings for both Internet gateways are the same, configure a peer group and specify it in the configuration of static BGP neighbors:
Create a route map that allows route information advertising to Internet gateways. Set the same BGP metrics as for DMVPN Spoke:
Add DMVPN cloud tunnel subnets to the advertised routes. Due to the specified route maps, information about tunnel routes will only be sent to Internet gateways.
For static BGP neighbors, also enable BFD protocol support:
Allow incoming BGP and BFD traffic to pass through the security zone configured on the subinterfaces of aggregated channels facing Internet gateways:
Now configure BGP neighbors towards the DMVPN Hub on the Internet gateway side. Due to the template nature of the settings towards the DMVPN Hub, use peer-group. Enable default route advertisement towards the DMVPN Hub, since traffic leaving the DMVPN cloud must be routed to the central office Internet gateways:
Create a route map that allows route information advertising towards Internet gateways.
Special attention should be paid to configuring BGP route metrics. Since each Internet gateway connects to Internet via its own Internet service provider, the default route advertised to the DMVPN Hub should be given higher priority by the Internet gateway that currently has access to the Internet. Since the RT-GW-1 Internet gateway configuration already has a configured tracking object that switches VRRP mastery for users in the central office local network, the same tracking object will be used in the route map to change the metric of the default BGP route that RT-GW-1 advertises to the DMVPN Hub.
Enable support for BFD protocol and increase BFD timers in the same way as is done for DMVPN Hub configuration:
Allow incoming BGP and BFD traffic to pass through the security zone configured on the subinterfaces of the aggregated channels towards the DMVPN Hub:
Configuring Zone-Based Firewall and Source NAT for remote office users
Since the DMVPN cloud that has now been created allows traffic from remote office users to exit via the central office's Internet gateway, additional firewall and NAT settings must be configured.
Start by allowing traffic from the DMVPN cloud to flow toward the central office's Internet gateways:
Now allow traffic from the DMVPN cloud to pass through to local users at the central office. To do this, create an IP address profile in which the addresses of the remote office subnets will be specified:
For this profile, allow access to local network users:
Also, allow traffic from the DMVPN cloud to access the Internet:
Add DMVPN Source NAT for traffic from the cloud. Perform Source NAT in the NAT pool already created for users of the central office:
At this point, the DMVPN configuration at the central office can be considered complete.