<

Cradlepoint and Cisco - DMVPN with Certificate Based Authentication (Also, IOS CA, OSPF, and VRRP)

Published on
4,310 Points
1,310 Views
Last Modified:
Editors:
I had to tackle a challenge to use Cradlepoint routers to provide backup WAN connectivity for my remote sites. This is how I did it.

Intro


This article runs through how I configured a WAN backup solution using Cradlepoint 1650 routers. The rest of my network was Cisco. I did not want to use the less secure means of authenticating VPN via a pre-shared key, so I went the certificate route, specifically by creating a Certificate Authority on the Cisco Router itself. Additional technologies necessary in this solution were GRE, VRRP, IOS CA, and OSPF.


I had a hard time finding any documents to show how to do the certificate authentication portion of this, so hopefully, this helps out a few people. All Cradlepoint configuration was done using the NetConnect management portal. This may look a little different if you are trying to follow this article when configuring a Cradlepoint directly.


For general information and/or config guides on the topics in this article, check out:



Note: Because this was from a production configuration, public IP's and company names have been removed/replaced. You would need to replace this information with your own appropriate settings.


Topology


To start off with, the high-level view of my topology



Hardware:

Cisco 4331 IOS-XE router, version 16.03.06

Cradlepoint AER1650, NetCloud OS 6.5.4


This is both pretty simple, and somewhat complicated all at the same time.


At the main site:


  • An internet-connected Cisco router that handles the VPN connectivity from all remote sites
  • A WAN-connected Cisco router that handles all the WAN connectivity from all remote sites
  • Beyond these routers are a mix of other devices including core routing, but that is not important for this walk-through.


At the remote site:


  • A WAN-connected Cisco router that serves as the primary router/gateway
  • A 3G/4G-connected Cradlepoint router. This has a dynamic IP address
  • All devices must use the Cisco router/Cradlepoint as their default gateway.


Goals of the project


  • Provide backup connectivity to the main site
  • Automatic failover between main (Cisco) and backup router (Cradlepoint)
  • Provide scalability to easily expand this solution to all remote sites
  • Utilize certificate-based authentication for the VPN. This is more secure than pre-shared keys and more scalable.


Certificate Configuration


We start with a basic router configuration:


BLDG42-RTR-VPN-01#show run
!
hostname BLDG42-RTR-VPN-01
!
!
clock timezone CST -6 0
clock summer-time cdt recurring
!
!
!
ip domain name company.com
!
!
interface Loopback0
ip address 172.16.248.42 255.255.255.255
!
interface GigabitEthernet0/0/0
description Internet
ip address 9.9.9.9 255.255.255.128
ip access-group inbound in
negotiation auto
!
interface GigabitEthernet0/0/1
description Inside/LAN
ip address 10.255.254.18 255.255.255.252
negotiation auto
!
!
router eigrp 10
network 10.0.0.0
passive-interface default
no passive-interface GigabitEthernet0/0/1
eigrp router-id 10.255.254.18
!
ip route 0.0.0.0 0.0.0.0 9.9.9.1
!
ip access-list extended inbound
permit esp any host 9.9.9.9
permit udp any host 9.9.9.9 eq isakmp
permit udp any host 9.9.9.9 eq non500-isakmp
permit icmp any any
denyip any any log
!
ntp server 10.1.254.250
!
end


BLDG42-RTR-VPN-01#


This gives us IP addressing, and internal/external routing. It is important that the router has correct date/time or the certificates will have incorrect times. The ACL permits VPN traffic from anywhere since the Cradlepoint(s) will not have a static IP. The ACL also allows Ping/ICMP from anywhere but denies any other traffic type.


To start things, we need to create a Certificate Authority (CA) on the headend, and also enroll the headend router with itself to generate an identity certificate. Then we will be able to get a certificate on the Cradlepoint.


CA High-level settings:


  • 2048 bit keys
  • SHA256 Signature Hash
  • 10 Year lifetime on the CA (well beyond the expected production life of the router itself)
  • 5 Year lifetime on the identity certificates


BLDG42-RTR-VPN-01#conf t
Enter configuration commands, one per line.End with CNTL/Z.
BLDG42-RTR-VPN-01(config)#ip http server


BLDG42-RTR-VPN-01(config)#crypto key generate rsa label CA-KEY modulus 2048 exportable
The name for the keys will be: CA-KEY


% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be exportable...
[OK] (elapsed time was 1 seconds)


BLDG42-RTR-VPN-01(config)#crypto pki trustpoint CA
BLDG42-RTR-VPN-01(ca-trustpoint)#rsakeypair CA-KEY
BLDG42-RTR-VPN-01(ca-trustpoint)#exit


BLDG42-RTR-VPN-01(config)#crypto pki server CA
BLDG42-RTR-VPN-01(cs-server)#issuer-name CN=BLDG42-RTR-VPN-01.company.com O=COMPANY L=Appleton ST=Wisconsin C=US
BLDG42-RTR-VPN-01(cs-server)#database url nvram:
BLDG42-RTR-VPN-01(cs-server)#database level complete
BLDG42-RTR-VPN-01(cs-server)#hash sha256
BLDG42-RTR-VPN-01(cs-server)#lifetime ca-certificate 3650
BLDG42-RTR-VPN-01(cs-server)#lifetime certificate 1825
BLDG42-RTR-VPN-01(cs-server)#grant auto
BLDG42-RTR-VPN-01(cs-server)#lifetime crl 24
BLDG42-RTR-VPN-01(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:


Re-enter password:


% Certificate Server enabled.
BLDG42-RTR-VPN-01(cs-server)#


!! Create a trustpoint and enroll with the CA server (which is on the router itself)




BLDG42-RTR-VPN-01(config)#crypto pki trustpoint CRADLEPOINTVPN.COMPANY.COM
BLDG42-RTR-VPN-01(ca-trustpoint)#enrollment url http://10.255.254.18:80
BLDG42-RTR-VPN-01(ca-trustpoint)# subject-name CN=BLDG42-RTR-VPN-01.company.com O=COMPANY L=City ST=State C=US
BLDG42-RTR-VPN-01(ca-trustpoint)#subject-alt-name CN=cradlepointvpn.company.com
BLDG42-RTR-VPN-01(ca-trustpoint)#revocation-check crl
BLDG42-RTR-VPN-01(ca-trustpoint)#auto-enroll
BLDG42-RTR-VPN-01(ca-trustpoint)#hash sha256
BLDG42-RTR-VPN-01(config)#crypto pki enroll CRADLEPOINTVPN.COMPANY.COM
% You must authenticate the Certificate Authority before
you can enroll with it.
% Attempting authentication first.


Certificate has the following attributes:
Fingerprint MD5: 32E12853 FF385591 XXXXXXXX XXXXXXXX
Fingerprint SHA1: 0D65C3F9 AAEF7B86 8E5186F3 XXXXXXXX XXXXXXXX


% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.


Password:
Re-enter password:


% The subject name in the certificate will include: CN=BLDG42-RTR-VPN-01.company.com O=COMPANY L=City ST=State C=US
% The subject name in the certificate will include: BLDG42-RTR-VPN-01.company.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose CRADLEPOINTVPN.COMPANY.COM' commandwill show the fingerprint.


BLDG42-RTR-VPN-01(config)#


Now we need to get the certificate on the Cradlepoint. 


First, obtain the CA certificate from the router


BLDG42-RTR-VPN-01(config)#crypto pki export CA pem terminal
% The specified trustpoint is not enrolled (CA).
% Only export the CA certificate in PEM format.
% CA certificate:
-----BEGIN CERTIFICATE-----
MIIDgDCCAmigAwIBAgIBATANBgkqhkiG9w0BAQsFADBRMU8wTQYDVQQDE0ZCTERH
NDItUlRSLVZQTi0wMS5pdHd3ZWxkcy5jb20gTz1JVFdXRUxEUyBMPUFwcGxldG9u
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
dCkfaDyjY28A07zmINOuWVCoHbfAHtoE61d5aHvmOLlIHA6dIOROBTp7ug1XWzRO
4uYuDElRaVE+yvwwjYOavp1ztqn1bUOj4ChKuJNbwSLb2m3D82Byns3tGV8TzdcP
HK1Y0gT4Jq/BUKIR4ulSOY/xtaX7j5MwfRfZnYWQDLr7aw9u
-----END CERTIFICATE-----


BLDG42-RTR-VPN-01(config)#


All lines from BEGIN CERTIFICATE to END CERTIFICATE need to be pasted into a file and saved. In my case, I named it CA_cert.crt


Now we need to move on to the Cradlepoint router to get a certificate request.


Go to the Cradlepoint router, Security --> Certificate Management --> Local Certificates --> Add

Fill in your information. Minimum requirements are Name, Country, and Common Name. Finish by clicking Save.



Download the CSR for that certificate. Go to Security --> Certificate Management --> Certificate Signing Request

Choose the certificate you created previously from the drop-down, choose your digest (SHA-256 in my case), and Download CSR.



Now we need to open the CSR file in a text editor so that we can copy/paste that info into the Cisco router to generate a certificate. You only need to copy the information between the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" lines.

 

BLDG42-RTR-VPN-01#crypto pki server CA request pkcs10 terminal
PKCS10 request in base64 or pem
 
% Enter Base64 encoded or PEM formatted PKCS10 enrollment request.
% End with a blank line or "quit" on a line by itself.
MIIDBTCCAe0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
----input omitted. This should include everything in the CSR
Between the BEGIN CERTIFICATE REQUEST and END CERTIFICATE
REQUEST----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
591+LIK42EhV
 
% Granted certificate:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
---output omitted---
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aw==

 

Create a certificate file by copying the information following "% Granted certificate:" and name it something like cisco_granted_cert.crt

The file should look like: 

 

-----BEGIN CERTIFICATE-----

MIIDvTCCAqWgAwIBAgIBBDANBgkqhkiG9w0BAQsFADBRMU8wTQYDVQQDE0ZCTERH

NDItUlRSLVZQTi0wMS5pdHd3ZWxkcy5jb20gTz1JVFdXRUxEUyBMPUFwcGxldG9u

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

aw==

-----END CERTIFICATE-----

  

At this point, you should have 3 files. The CA certificate, the CSR from the Cradlepoint, and the Cisco granted certificate. To bring this all together, we need to export the full certificate from the Cradlepoint (the one you added in order to create the CSR). 


Go to Security --> Certificate Management --> PKCS12


In the Export section, choose your certificate, enter a passphrase (of your choosing), and then Export/Download Certificate. This will come to you in p12 format.



Now we need to use OpenSSL to pull the private key from the p12 you just downloaded and use that to combine the private key, Cisco granted certificate and the CA certificate in a chain. In my specific instance, I have the following filenames:


  • BLDG18-RTR-CRADLEPOINT-01.csr   <-- the certificate signing request from Cradlepoint
  • BLDG18-RTR-CRADLEPOINT-01.p12  <-- the exported certificate from Cradlepoint
  • CA_cert.crt  <-- the Cisco IOS CA certificate
  • cisco_granted_cert.crt  <-- the Cisco granted certificate


On the command line, using OpenSSL:


C:\Program Files (x86)\GnuWin32\bin>openssl pkcs12 -in BLDG18-RTR-CRADLEPOINT-01.p12 -nocerts -nodes -out private_cert.key
Enter Import Password: (Enter password that you used when exporting from Cradlepoint)
MAC verified OK


The above will pull the private key from the certificate and save it as 'private_cert.key'

The below command will bring files together to form a certificate chain


C:\Program Files (x86)\GnuWin32\bin>openssl pkcs12 -export -out finalBLDG18-RTR-CRADLEPOINT-01.p12 -inkey private_cert.key -in cisco_granted_cert.crt -certfile CA_cert.crt
Loading 'screen' into random state - done
Enter Export Password:
Verifying - Enter Export Password:


C:\Program Files (x86)\GnuWin32\bin>


If you don't have OpenSSL, head over to OpenSSL to obtain the software for free.


Now I have a grand total of 6 files



Take the final certificate file you created and import it on the Cradlepoint. 

Go to Security --> Certificate Management --> PKCS12

In the Import section, type in a name (of your choosing), the passphrase you used in the last step of the OpenSSL commands, and then select the final certificate file. Then Import/Upload Certificate



If all is well, you will get a message that the import was a success, and you will see it in Security --> Certificate Management --> Local Certificates


You'll actually see it twice because Cradlepoint will create a CA trust certificate as well as the identity certificate. If you don't have a pair of certificates (name & name(CA) ) you will not be able to use the certificate for VPN authentication.


And finally, go to Networking --> Tunnels --> IPSec VPN, choose the Global Settings tab, choose your certificate and save.



That completes the certificate portion of this build out. When you have multiple remote sites, you would only need to create the Cisco IOS CA once, and then each remote site would need to go through the process to request and install a certificate from the CA if you require that each router need a unique certificate. You can actually utilize the same identity certificate for multiple routers. 


This does make life a little easier, but it does come with some disadvantages. If you ever need to revoke the certificate due to compromise, you now revoked the certificate from ALL routers that use it. Also, when the one certificate expires, it expires on all routers simultaneously. You also have no option to differentiate between routers when they identify themselves identically with the same certificate. Food for thought.


VPN Configuration (DMVPN)


High-level settings

IKEv1

Phase 1

  • encryption AES 256
  • hash SHA 256
  • DH group: 14
  • Lifetime: 2880

Phase 2

  • encryption AES 256
  • hash SHA2 256
  • PFS - no


Since this is dealing with remote sites that have dynamic IP addresses, the headend router won't have any peer IP addresses defined. Further, I am using stronger encryption/hash settings than you might see on the average configuration guide. 


In your own network, the phase1 & 2 policies just need to match on both sides for successful connections. Enabling reverse-route allows us the option to use a routing protocol to distribute routes into the network. Also, since we are using certificates, we will need a certificate map to look for appropriate attributes.


!!Note - 'the crypto isakmp identity dn' command is very important. I spent many hours trying to get certificate authentication working and that command was a key missing config line. The default identity that Cisco uses (address) will cause Cradlepoint be unable to authenticate the Cisco router's certificate


The Cradlepoint's configuration for IPSec/GRE/DMVPN/NHRP/OSPF all kind of tie together, so we'll configure it all at once on each device before testing it out. Before complicating things, my initial configuration for OSPF on the Cisco router is just enough to get a neighbor relationship.


BLDG42-RTR-VPN-01(config)#crypto pki certificate map CP-CERT-MAP 10
BLDG42-RTR-VPN-01(ca-certificate-map)# issuer-name eq CN=BLDG42-RTR-VPN-01.company.com O=COMPANY L=City ST=State C=US


BLDG42-RTR-VPN-01(config)#crypto isakmp policy 10
BLDG42-RTR-VPN-01(config-isakmp)# encr aes 256
BLDG42-RTR-VPN-01(config-isakmp)# hash sha256
BLDG42-RTR-VPN-01(config-isakmp)# group 14
BLDG42-RTR-VPN-01(config-isakmp)# lifetime 28800
BLDG42-RTR-VPN-01(config-isakmp)#crypto isakmp identity dn


BLDG42-RTR-VPN-01(config)#crypto isakmp profile cradlepoint-cert
BLDG42-RTR-VPN-01(conf-isa-prof)#ca trust-point CRADLEPOINTVPN.COMPANY.COM
BLDG42-RTR-VPN-01(conf-isa-prof)#match certificate CP-CERT-MAP
BLDG42-RTR-VPN-01(conf-isa-prof)#!
BLDG42-RTR-VPN-01(conf-isa-prof)#!


BLDG42-RTR-VPN-01(conf-isa-prof)#crypto ipsec transform-set ESP-AES-256-SHA esp-aes 256 esp-sha256-hmac
BLDG42-RTR-VPN-01(cfg-crypto-trans)# mode tunnel
BLDG42-RTR-VPN-01(cfg-crypto-trans)#!


BLDG42-RTR-VPN-01(cfg-crypto-trans)#crypto ipsec profile DMVPN
BLDG42-RTR-VPN-01(ipsec-profile)# set transform-set ESP-AES-256-SHA
BLDG42-RTR-VPN-01(ipsec-profile)# set isakmp-profile cradlepoint-cert
BLDG42-RTR-VPN-01(ipsec-profile)#!
BLDG42-RTR-VPN-01(ipsec-profile)#


BLDG42-RTR-VPN-01(ipsec-profile)#interface Tunnel42
BLDG42-RTR-VPN-01(config-if)# ip address 10.255.8.42 255.255.255.0
BLDG42-RTR-VPN-01(config-if)# no ip redirects
BLDG42-RTR-VPN-01(config-if)# ip nhrp authentication $VPN2018
BLDG42-RTR-VPN-01(config-if)# ip nhrp network-id 1
BLDG42-RTR-VPN-01(config-if)# ip nhrp redirect
BLDG42-RTR-VPN-01(config-if)# ip ospf network broadcast
BLDG42-RTR-VPN-01(config-if)# ip ospf priority 255
BLDG42-RTR-VPN-01(config-if)# keepalive 10 3
BLDG42-RTR-VPN-01(config-if)# tunnel source GigabitEthernet0/0/0
BLDG42-RTR-VPN-01(config-if)# tunnel mode gre multipoint
BLDG42-RTR-VPN-01(config-if)# tunnel key 2018
BLDG42-RTR-VPN-01(config-if)# tunnel protection ipsec profile DMVPN


BLDG42-RTR-VPN-01(config-if)#router ospf 1
BLDG42-RTR-VPN-01(config-router)# router-id 10.255.8.42
BLDG42-RTR-VPN-01(config-router)# passive-interface default
BLDG42-RTR-VPN-01(config-router)# no passive-interface Tunnel42
BLDG42-RTR-VPN-01(config-router)# network 10.255.8.0 0.0.0.255 area 0


Now for the Cradlepoint configuration. Different components reference on another, so we have to configure this in order or we'll be doing a lot of jumping back and forth.

 

Go to Networking --> Tunnels --> GRE --> Add

The tunnel key must match was was configured on the Cisco router, local endpoint is the tunnel IP address, and make sure to enable Multicast if you are running a routing protocol like OSPF.



Steps 2 and 3 didn't need additional configuration.




Go to Networking --> Tunnels --> IPSec VPN --> Add

Make sure to check Anonymous Mode



Although it may seem counterintuitive if DMVPN is new to you, we do not specify local or remote networks. When the policy is attached to the GRE tunnel, the local/remote network automatically uses the public IP addresses for ipsec/phase 2 (at least that's how I understand it). From there we can assume that we're routing over GRE so having additional IPSEC endpoints defined would be of no use.



Again, because we chose GRE as the protocol in step 1, the remote gateway cannot be configured here as the GRE tunnel itself provided the remote destination. Well, had we configured a remote gateway on the GRE tunnel, the tunnel would have provided that info. We will actually get that info from the NHRP configuration.



Steps 4 and 5 define phase 1 and phase 2 encryption/hash settings. This needs to match your settings on the Cisco router




Step 6 was left at the defaults



Go to Networking --> NHRP --> Add

The peer authentication needs to match the Cisco router

The VPN drop down will list the IPSec policy you made before.



Static Peer Map --> Add.

Protocol address is the tunnel IP address of the other end (Cisco Router)

NBMA address is the public IP address

Make sure to check the register box

(this is how the IPSec policy gets its remote gateway/destination address)




Go to Networking --> Routing --> OSPF --> Add



The interface will be the GRE tunnel we made earlier


Network type needs to be non-broadcast as DMVPN remote sites cannot 'broadcast' to find a neighbor across a GRE tunnel


Priority should be 0 so that the remote site cannot be a DR/BDR



From here on out, this is really dependent upon your own OSPF needs. For this tutorial, I am only adding enough to activate OSPF on the tunnel interface and one LAN interface I have defined previously (not part of this tutorial)






At this point, I have completed the DMVPN portion of the configuration. On the Cisco router, we can see the tunnel is up and we can ping across the GRE tunnel interface.


BLDG42-RTR-VPN-01#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
x.x.x.x         x.x.x.x         QM_IDLE        20644 ACTIVE

IPv6 Crypto ISAKMP SA

BLDG42-RTR-VPN-01#ping 10.255.8.101 source tunnel 42
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.255.8.101, timeout is 2 seconds:
Packet sent with a source address of 10.255.8.42
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 49/62/103 ms
BLDG42-RTR-VPN-01#


ROUTING AND REDUNDANCY CONFIGURATION


So far, we've configured the CA, produced some certificates, and configured all the necessary components for DMVPN with certificate-based authentication. As part of the DMVPN configuration, we also have basic routing connectivity.


From the VPN headend router, we can see an OSPF neighbor and a couple routes. The routes I'm receiving are based on the interfaces I included in the OSPF configuration.


BLDG42-RTR-VPN-01#show ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.8.101      0   FULL/DROTHER    00:00:37    10.255.8.101    Tunnel42
BLDG42-RTR-VPN-01#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 9.9.9.129 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 332 subnets, 8 masks
O        10.167.101.0/24 [110/1010] via 10.255.8.101, 00:22:32, Tunnel42
O        10.168.101.0/24 [110/1010] via 10.255.8.101, 00:22:32, Tunnel42
BLDG42-RTR-VPN-01#


One of the project goals was to provide redundancy between the main router (Cisco) and the back router (Cradlepoint) so that users at the remote site would experience little to no outage in the event of a WAN failure. To do this, I'll configure VRRP. Under normal circumstances, I want the Cisco router to be the master VRRP router. VRRP is a First Hop Router Redundancy (FHRP) protocol. It's a means to allow two gateways/routers to "share" an IP address. From the client's point of view, it gets assigned an IP and 1 default gateway, and the FHRP allows that gateway IP address to be essentially assigned to both routers at the same time. The Master/Backup status is what determines which router will actively respond to traffic destined for the default gateway IP address.


This configuration is pretty straightforward. For a given interface, you have VRRP configuration.


BLDG18-RTR-01#show run
Building configuration...

Current configuration : 248 bytes
!
! Only showing relevant config
!
track 42 ip sla 52
!
track 52 ip sla 52
!
track 167 list boolean or
 object 42
 object 52
!
track 168 list boolean or
 object 42
 object 52
!
ip sla 42
 icmp-echo 10.255.12.42 source-interface GigabitEthernet0/0/0
 timeout 15000
 frequency 15
ip sla schedule 42 life forever start-time now
ip sla 52
 icmp-echo 10.255.12.52 source-interface GigabitEthernet0/0/0
 timeout 15000
 frequency 15
ip sla schedule 52 life forever start-time now
ip sla responder
!
interface Vlan167
 description Data
 ip address 10.167.101.249 255.255.255.0
 vrrp 167 ip 10.167.101.250
 vrrp 167 preempt delay minimum 60
 vrrp 167 priority 150
 vrrp 167 track 167 decrement 100
end


The first part of this config can seem a little complicated, but the concept is easy enough to understand. With VRRP (and other FHRP's), there needs to be a way to determine how and when a backup router takes over as master. Without any other configuration, VRRP would essentially require that the VRRP interface goes down or the entire device fails. That would cause the remaining VRRP routers to elect a new master due to the missing keepalives from the original master. 


That's all well and good, but nowadays it's more common to see a WAN link failure than a complete device failure. To make matters more complicated, ISP hand-offs are often times not a direct connection to the ISP gateway. You may get an Ethernet hand-off at the remote site, but there's a good chance that the ISP is simply extending Layer2 from a central office to your branch site. There could easily be a failure at the central office (or somewhere in the ISP network) that causes routing to fail even though the physical interface at the remote site is up. To accommodate this possibility, I have configured IP SLA tracking rules that essentially tell the router to ping two different IP addresses (happens to be the two WAN headend routers), and if either of them are reachable the WAN must be up. If they are both down, the Track 167 object is down.


For the interface configuration, what this means is that the Cisco router will have IP address 10.167.101.249/24 configured on VLAN 167. The VRRP IP address is 10.167.101.250. This is the floating address that clients will use as a default gateway. Configuring preempt says that the router will actively attempt to become the master (say after a reboot when the Cradlepoint had become the master for a while). The added delay gives the router time to establish connections and WAN routing adjacencies before trying to take over as master. Further, if the Track 167 object is down (WAN failure), decrement the priority - this will cause the Cradlepoint to take over as the master even though the Cisco router itself is still up and functional.


The Cradlepoint configuration is straightforward and just needs to match the Cisco.



Once this configuration is applied, we can see the Cisco become the Master, and if I cause the Track 167 object to go down, it will lower its own priority and become the backup.


BLDG18-RTR-01#show vrrp interface vlan 167
Vlan167 - Group 167
  State is Master
  Virtual IP address is 10.167.101.250
  Virtual MAC address is 0000.5e00.01a7
  Advertisement interval is 1.000 sec
  Preemption enabled, delay min 60 secs
  Priority is 150
    Track object 167 state Up decrement 100
  Master Router is 10.167.101.249 (local), priority is 150
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.414 sec


! I disconnected the WAN interface to cause the Track 167 object to go down

BLDG18-RTR-01#show vrrp interface vlan 167
Vlan167 - Group 167
  State is Backup
  Virtual IP address is 10.167.101.250
  Virtual MAC address is 0000.5e00.01a7
  Advertisement interval is 1.000 sec
  Preemption enabled, delay min 60 secs
  Priority is 50  (cfgd 150)
    Track object 167 state Down decrement 100
  Master Router is 10.167.101.248, priority is 100
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.414 sec (expires in 2.937 sec)

BLDG18-RTR-01#


That should do it. Project completed (right?)


The Goals were:


  • Provide backup connectivity to the main site
    • This was done by adding the Cradlepoint router to the network with cellular connectivity. IPSEC DMVPN provided the backup path to the main site.
  • Automatic failover between main (Cisco) and backup router (Cradlepoint)
    • By configuring VRRP, clients will transparently failover between the Cisco and Cradlepoint router
  • Provide scalability to easily expand this solution to all remote sites
    • DMVPN itself is a scalable technology, and the Cradlepoint NetCloud further assists this by allowing group configurations so that I can apply common configurations to multiple routers.
  • Utilize certificate-based authentication for the VPN. This is more secure than pre-shared keys and more scalable.
    • This was the first task we tackled by using the VPN headend router as a Certificate Authority


CONCLUSION


This was a lot of work, but totally worth it. We now have a backup to our WAN connection, it's using certificates for authentication, it is easily scalable.


Big thanks to Cisco TAC and Cradlepoint support as I wouldn't have been able to figure this out without you!



0
Author:rauenpc
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free