IKEv2 profile is chosen based on FVRF and IKEv2 identity of an incoming request (matched by certificate-map).The same certificate is used for both local and remote authentication.IKEv2 ID is set equal to certificate’s DN.Spoke selects a certificate based on the configured trustpoint (PKI-CLOUD-1).Spoke selects a particular IKEv2 profile based on its interface’s IPSec profile.This is how IKEv2 profile is used on the initiating side (Spoke): Tunnel protection ipsec profile IPSEC - CLOUD - 1 The details of IP address assignment will be discussed in the following sections. IP address for SVTI could be defined statically or assigned by the Hub. Spoke’s SVTI will have both source, destination and FVRF name defined. To get things started you’d need to setup a static VTI (SVTI) on the Spoke and Dynamic VTI (DVTI) on the Hub. Tunnel mode could be either ipsec ipv4 or gre, however NHRP protocol only works over GRE so we’ll stick with the default mode. Both Hubs and Spokes use Virtual Tunnel Interfaces (VTIs) to setup direct communication channels over the WAN. Let’s start with the most basic configuration construct – a tunnel interface. Throughout this section, if configuration is the same for both FlexVPN clouds, I will only include examples for one of them.
#NAME MANGLER FAQ FULL#
Instead of providing the full show run outputs here, I’ve decided to split FlexVPN configuration into a number of small building blocks and examine them separately. Front door VRF (FVRF) has been pre-configured on all devices with correct ip address and default route.Įven though PKI setup is not covered in this post, I would still like to include an example of how trustpoint for Cloud 1 will be configured on SPOKE-3:.Organisational Unit (OU) attribute of X.509 certificate will be used to encode site’s bandwidth:.All Spokes have one unique certificate per FlexVPN cloud.All devices in one cloud will have their certificates signed by the same CA and have a common domain portion of the CN attribute (cloud.one or cloud.two).Each FlexVPN cloud has its own Certificate Authority (CA).I will assume that PKI infrastructure is already setup in the following way:.In this post I will not focus on particular design choices and will follow best practices outlined in FlexVPN Overview and Design post. Before we jump to FlexVPN configuration let me go over some of the assumptions I’ve made about pre-existing state of the network: To demonstrate some of the corner case scenarios SPOKE-1 and HUB-1 will both have dual WAN links and should have automatic failover capabilities. Each Spoke will have a unique certificate per-cloud and will connect to both FlexVPN Hubs. Each FlexVPN cloud is represented by its own domain encoded in Common Name (CN) attribute of X.509 certificate. The network we’ll be looking at is a dual-hub dual-cloud FlexVPN with PKI authentication. For most patient readers there’s a bonus at the end of this post. I’ll show what components are involved in configuration and how they all tie together. In this post we’ll have a look at the process of configuring a FlexVPN network (unofficially known as DMVPN phase 4).
0 kommentar(er)
