×

Message

PLG_KUNENADISCUSS_DEPENDENCY_FAIL

 

SPOKE TO SPOKE FLEXVPNs

INTRODUCTION

In most of the VPN deployments that we have done so far, they have been based on a Hub and Spoke topology. That is to say that the spoke routers do not communicate directly with each other. If one spoke wants to communicate with another spoke router, then it has to go through the Hub router. Most scenarios require this kind of deployment where the security policy of the company dictates that all spoke to spoke communications must pass through the Hub router.

 

But there are scenarios or situations where this is not a viable solution. For example if your company is running applications that are delay sensitive in nature such as Voice and Video over IP (VoIP). In this case you might want a network that implements spoke to spoke VPN communications such as the one we saw earlier when we were dealing with DMVPNs.

 

In this article we are going to see how we will take all the advantages that comes with FlexVPNs and add to it dynamic spoke to spoke communications between VPN peers.

 

For us to achieve spoke to spoke FlexVPN communication, we are going to leverage the services of NHRP protocol which we used in DMVPNs earlier in the DMVPNs deployment. This will enable spokes to build direct paths to each other so they don’t have to forward all the traffic to the Hub anytime we want to have spoke to spoke communications.

 

IMPLEMENTATION

In our implementation for this scenario we are going to have our usual four routers, one Hub (Kisii Router) and three spokes (Nairobi, Mombasa and Kisumu Routers). NHRP commands will be issued both at the Hub and spokes as appropriate to enable a dynamic spoke to spoke FlexVPNs communications.

 

Also in this network the spoke routers will learn their tunnel interface addresses from the Hub’s local pool defined for this purpose. It is part of the IKEv2 Authorization policy as we saw in the previous article.

 

NETWORK TOPOLOGY DIAGRAM

 

 

We are going to verify an already configured network to see Spoke-to-Spoke FlexVPNs in action.

 

Step 1: Verification of routes learned by the Hub and spokes

Each router advertises its own routes as defined in the IKEv2 authorization policy.

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

 

The Kisumu Router:

 

 

Step 2: Verify the IKEv2 Security Association

Verification of IKEv2 security association verifies that our routers have formed the first tunnel in the VPN process. This tunnel is used for management traffic between the VPN peers.

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 3: Verify the IPSec Security Associations (SAs)

The IPSec tunnel is the second tunnel in the VPN process. This tunnel is responsible for passing user data traffic.

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 4: Verification of the NHRP

The Next Hop Resolution Protocol (NHRP) make the process of spoke to spoke communication possible. In order for the spoke routers to dynamically form direct VPN sessions and send to each other data directly, NHRP must do its magic.

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 5: Trace Routing Remote LAN Subnets from local LAN Subnet

This is the ultimate verification step that shows us if NHRP is working correctly. If NHRP is working correctly, when pinging remote subnets, we should have direct connection without passing at the Hub (Kisii) router.

 

Since our main goal for this article is for us to have direct spoke to spoke communication, I will be verifying spoke to spoke communications.

 

The Nairobi Router:

 

As you can see in the figure below, the Nairobi router can reach Mombasa and Kisumu router LAN network in one Hop as show below. In other words, NHRP is working super fine since we have a direct connection from our Nairobi router to the Mombasa and also from the Nairobi to Kisumu router through the dynamic virtual access interfaces they have formed from the virtual template. The process is the same for all the other spoke routers.

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

THE END

 

 

FLEXVPNs CLIENTS & PUSHING ROUTE INFORMATION

As we have said and seen before, FlexVPN is so much flexible and full of cool features that enable you to have about anything you may ever want in your VPN deployment.

 

It lets us set up multiple Head-end Hub peers that we can possibly connect to for fault tolerance. If the Hub fails in a VPN deployment, then all the VPN spokes are also affected and cannot function. This is way it is always important to plan for redundancy early on in the design stage of your VPN deployment and not an afterthought.

 

FlexVPNs also enables the spoke routers and the Hub to exchange routes without needing a dynamic routing protocol to route the LAN routes from one router to another. This demonstration takes the network we implemented in the last article and then now we are going to have our spoke routers configured as full blown FlexVPN clients.

 

1.     The following list points out some of the changes that we are going to have on the spoke routers so that they can be FlexVPN clients.

·        An AAA Network Authorization method list will be added on the spoke routers just as we had it in the Hub router.

 

·        We will have an ACL to identify the routes to advertise/push to the server

 

·        We will also have an IKEv2 Authorization policy that will call on the ACL.

 

·        The IKEv2 authorization policy will be added to the IKEv2 profile

 

·        Another significant thing to note is that we are going to have our tunnel destination as dynamic instead of static.

 

·        Create the FlexVPN peers in the FlexVPN Client configuration Mode.

 

IMPLEMENTATION

In this demonstration we are going to have the four usual routers taking part in this VPN process. The main focus on this demonstration is to show you how you can configure a policy on the FlexVPN Clients (Spokes) and then have the tunnel interface be dynamic instead of static.

 

In this demonstration we are going to have the Nairobi router push the routes 10.2.2.0/24, 10.22.22.0, and 172.16.22.0/24 to the Hub router (Kisii Router), also the Mombasa router will push 10.3.3.0/24, 10.33.33.0/24 and 172.16.33.0/24 and the Kisumu router will push 10.4.4.0, 10.44.44.0, and 172.16.44.0/24 to the Hub router. Note that there is no need to configure a routing protocol to achieve this.

 

NETWORK TOPOLOGY DIAGRAM

 

 

Step 1: Verify the AAA related commands

In this first step we are to verify the AAA network authorization method list as well as if AAA has been enabled on the router.

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

  

Step 2: Verifying the ACL that identifies the routes to be pushed to the Hub

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 3: Verify the spoke routers’ tunnel interface destinations are dynamic

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 4: Verifying the IKEv2 Authorization Policy

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 5: Verifying the application of IKEv2 authorization policy to IKEv2 profile

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

The Mombasa Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 7. Verifying routes learned from the spoke by the Hub

 

This is the most important part of the verification. Here we are going to verify if the routes pushed by the Spoke routers have been learned by the Hub router.

 

The Kisii Hub Router:

 

 

THE END

 

 

FLEX VPNS: IKEv2 PUSHING POLICY

 

In this article/demonstration, we are going to show you how a Hub router, in this case the KISII Router, can be configured to introduce AAA Authorization in combination with FLEX-VPNs in order to push out policy out to the devices that are connecting to the Hub over the VPNs.

 

Flex-VPNs can be seen as all you may need for all your VPN needs. In this demo we are going to have a dynamic VTI Hub and Static Tunnel interfaces on the spoke. We will have almost the same configurations as we had in the previous article for the base network but with added configurations/components. The added components on the Hub router are:

 

1.     AAA Network Authorization Method List.

 

2.     IKEv2 Authorization Policy.

 

3.     IP Local Pool.

 

4.     Adding the Authorization Policy to the IKEv2 Profile.

 

Also in this demonstration we are going to push a policy down to the spoke routers from the Hub where the spoke routers are required to learn their Tunnel interface IP addresses from a pool of addresses configured on the Hub router. The range of the addresses to be learned is: 172.16.0.150 – 172.16.0.250. Spoke routers will use IP addresses from this range instead of the IP Unnumbered addresses they were using previously.

 

IMPLEMENTATION

In this demo, we are going to have one Hub router which is the Kisii router and three spoke routers which are the Nairobi, Mombasa and the Kisumu City routers. The aim of this short demonstration will be to show you how a policy can be implemented on the Hub router and be learned by all the spoke routers in the network.

 

NETWORK TOPOLOGY DIAGRAM

 

 

Step 1: Verify the spoke interfaces before the policy is applied.

 

This step verifies the status of the spoke routers before the policy is applied to the hub routers requiring the spoke routers to receive their tunnel interfaces from the hub router from a pre-configured pool. As you can see in the following figures is that all the spoke routers are using the IP Unnumbered feature which borrows the interface Loopback 0’s ip address. That is to say that the Nairobi router will be using the 2.2.2.2 which it borrows from the loopback 0 interface, as well as the Mombasa Router (3.3.3.3) and the Kisumu router (4.4.4.4) which they all borrow from their loopback interfaces as shown below.

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 2: Verify the spoke tunnel interfaces after the policy application

 

In this step of verification, we are going to see if the spoke routers have learned their new IP addresses from the Hub router (The KISII Router) and the IP addresses should be taken from the pool 172.16.0.150 – 172.16.0.250 as shown in the diagrams below.

 

The Nairobi router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 3: Verify the AAA Network Authorization Method List

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 4: Verify the IKEv2 Authorization Policy.

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 4: Verify the IP Local Pool on the Hub Router

 

The Kisii Router:

 

 

THE END

 

 

DYNAMIC VTI WITH IKEv2 HUB AND SPOKE RSA-SIG

 

INTRODUCTION

Previously when we were dealing with Dynamic Virtual Tunnel Interfaces (DVTI), we deployed in IKEv1. Now we get the opportunity to do so in IKEv2 also at the same time using Digital Signatures. We are going to leverage the digital signatures from the last article we just implemented. (IKEv2 RSA-SIG AUTHENTICATION).

 

In this scenario, we are going to create/verify a dynamic virtual-template on the Hub router (KISII-CITY-ROUTER), and on the spoke routers (all other routers) are going to implement static tunnel interfaces.

 

When the spoke routers come to form a VPN tunnel with the Hub, the hub curves out a virtual-access interface from the virtual template interface for each VPN peer it forms a VPN Tunnel with. I think by now it should be clear that implementing a Dynamic Hub is much more scalable that a static tunnel interface hub. Also there are numerous advantages of having a digital signatures based VPN Peer authentication in you VPN deployment.

 

IMPLEMENTATION

In our demonstration network we are going to use almost the same network topology as we used in the last article/example. The major emphasis of this demonstration is to show a Dynamic VTI IKEv2 Hub and static tunnel spokes, as well as the use of RSA Digital signatures.

 

NETWORK TOPOLOGY DIAGRAM  

 

 

 

We are going to verify an already configure network shown above, all the IKEv2 Dynamic VTI Hub and Spoke related configurations.

 

Step 1: Verify the Virtual Access Interfaces on the Hub router (KISII ROUTER)

 

The Kisii Router:

 

 

Step 2: Verify IKEv2 Security Associations (SAs)

 

The Kisii Router:

 

 As you can see in the following diagram, this Kisii router has formed three security associations with the three spoke routers. Also note that the router is using RSA Digital Signatures for VPN Peer authentication.

 

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 3: Verify the IPSEC SA

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 4: Verify Routes/Networks Learned from Other VPN peers

 

The Kisii Router:

 

This Kisii City router which happen to be the Hub router, has learned the routes/networks 10.2.2.0/24 from the Nairobi router, 10.3.3.0/24 from the Mombasa Router, 10.4.4.0/24 from the Kisumu router as shown in the diagram below using the EIGRP Routing Protocol.

 

 

The Nairobi Router:

 

Since this is a spoke router and there is no direct spoke to spoke communications, this router learns all the LAN Networks/Routes 10.1.1.0/24, 10.3.3.0/24, and 10.4.4.0/24 though the static tunnel interface (Tunnel 0) that it forms with the Kisii Router (1.1.1.1) which is the Hub router as show in the figure below.

 

 

The Mombasa Router:

 

Since this is also a spoke router and there is no direct spoke to spoke communications, this router learns all the LAN Networks/Routes 10.1.1.0/24, 10.2.2.0/24, and 10.4.4.0/24 though the static tunnel interface (Tunnel 0) that it forms with the Kisii Router (1.1.1.1) which is the Hub router as show in the figure below.

 

 

The Kisumu Router:

 

Since this is also a spoke router and there is no direct spoke to spoke communications, this router learns all the LAN Networks/Routes 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 though the static tunnel interface (Tunnel 0) that it forms with the Kisii Router (1.1.1.1) which is the Hub router as show in the figure below.

 

 

THE END.

 

 

 

IKEv2 RSA-SIG AUTHENTICATION

So far our IKEv2 implementations have been based on pre-shared keys when it comes to authentication of VPN peers. There are two major problems (sort of) that may result from using pre-shared keys. First, pre-shared keys are not scalable as compared to digital signatures. Second, using pre-shared keys in a large or rapidly expanding network is secure. Pre-shared keys are not that secure as compared to digital signatures.

 

IKEv2 RSA_SIG Authentication is a bit different compared to the IKEv1 way of doing RSA-SIG Authentication. First we will be using a certificate map for matching. Also, there are changes in the IKEv2 profile in that the matching of the VPN peer is no longer based on the pre-shared keys but on the Certificate Map. Also the authentication type is based on RSA-SIG not pre-shared keys. The last change in the IKEv2 profile is that we no longer specify the Key Ring but rather we will be specifying the trustpoint which links to the CA Server that we trust.

 

Another important thing to note is that we don’t need to create a Key Ring on the global configuration mode, instead we will have a certificate map in its place.

 

IMPLEMENTATION

In this demonstration, we are going to show you a network that has already implemented the RSA-SIG for VPN authentication in an IKEv2 based network. We are going to verify all the Digital Signatures related items in this deployment.

 

These include receiving the identity cert and authenticating the CA Server (Receiving the Digital Cert for the CA), Verifying that this deployment has successfully used digital signatures for VPN Peer authentication.

 

Following is the network topology that we are going to use for this demonstration.

 

 NETWORK TOPOLOGY DIAGRAM

 

 

 

Step 1: Verify both the Identity and CA certs for each router

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

Step 2: Verify that the RSA Digital Signatures are being used for authentication

 

The Kisii Router:

 

 

The Nairobi Router:

 

 

The Mombasa Router:

 

 

The Kisumu Router:

 

 

THE END

 

Go to top