VPNs for CCIE Candidates ?? A much needed topic when i was doing my practice and studies for CCIE RS and SEC tracks, since i am doing now my CCIE SEC preparation i would love to draft this topic in a professional and understandable manner which combines the methods and types of VPNs’ which are mostly used on IOS and Cisco FW. I have started this to have some mimics on how actually memorize the methods of different types of VPNs.
VPNs sounds familiar and simpler for NON CCIE candidates but believe me they are much complicated and complex in terms of configuration then rocket science 🙂 This will be long Topic ever which has all the Types of VPN described in single post.
So let’s start our discussion on well-know types of VPN configurable on Cisco IOS: ( We will have brief overview of the VPN types and then a short lab for it to conclude it’s working condition and place of use ):
(Cisco): The Dynamic Multipoint VPN (DMVPN) feature allows users to better scale large and small IPSec VPNs by combining generic routing encapsulation (GRE) tunnels, IPSec encryption, and Next Hop Resolution Protocol (NHRP) to provide users with easy configuration through crypto profiles, which override the requirement for defining static crypto maps, and dynamic discovery of tunnel endpoints.
The feature works according to the following rules KEY RULES
- Each spoke has a permanent IPSec tunnel to the hub.
- When a spoke needs to send a packet to a destination subnet on another spoke, it queries the NHRP server for the real address of the destination spoke.
- After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPSec tunnel to the target spoke.
- The spoke-to-spoke tunnel is built over the multipoint GRE (mGRE) interface.
- The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.
This means that we will have Hub-Spoke topology where we use DMVPN to avoid static crypto maps and automate tunneling. The basic lab for demonstration we will have blow topology:
For illustration we will have above lab build in UNETLAB and will proceed with configuration, we have already did initial reachability for the lab and used Windows 7 for TEST purpose as client USER1 and USER2. The steps for having DMVPN setup is as below:
1. Define Phase 1 Crypto ISAKMP Policy:
2. Define Dynamic Pre-Share Key for Remote Sites:
3. Define Phase 2 Policy for Data Encryption:
4. Define IPSec Profile for GRE over IPSec Tunnel:
5. Define GRE Tunnels:
6. Define Routing Protocol for Private network (172.16.123.x/24):
When Tunnel is configured ISAKMP process should be ON, now moving to the Spokes:
Process 1,2,3,4 and 6 are same as described above except step 5, tunnel configuration of Spoke 1 and Spoke 2 are as below:
As soon as the Tunnel’s are UP you will have Eigrp Adjacency established between all the three routers, to verify:
Verification on HUB:
VERIFICATION PC (USER1) TO PC (USER2):
Cool and Perfect our DMVPN between sites are up now let’s move on with other VPN Type which is:
Cisco Easy VPN is an IP Security (IPsec) virtual private network (VPN) solution supported by Cisco routers and security appliances. It greatly simplifies VPN deployment for remote offices and mobile workers. Cisco Easy VPN is based on the Cisco Unity Client Framework, which centralizes VPN management across all Cisco VPN devices, thus reducing the management complexity of VPN deployments.
There are three components of the Cisco Easy VPN solution:
- Easy VPN Client
The Cisco Easy VPN Client enables mobile workers to create a remote-access VPN connection to a Cisco Easy VPN Server. Cisco Easy VPN Client refers to the Cisco VPN Client, which is also commonly referred to as the Cisco Software VPN Client.
2. Easy VPN Remote
The Cisco Easy VPN Remote enables Cisco routers and security appliances to establish a site-to-site VPN connection to a Cisco Easy VPN Server without complex remote-side configuration. Cisco Easy VPN Remote is also commonly referred to as a hardware client.
3. Easy VPN Server
The Cisco Easy VPN Server accepts connections from Cisco Easy VPN Client and Remote, ensures that those connections have up-to-date policies in place before the connections are established. All Cisco Easy VPN Servers are interoperable with all Cisco Easy VPN Client and Remote.
The Cisco Easy VPN solution uses the Mode-Configuration (Mode-Config) mechanism within the Internet Key Exchange (IKE) to push policy (attributes) from the Easy VPN Server to the Easy VPN Client or Remote. Since this policy is pushed to the client or the remote every time a new tunnel is created, it makes it easier to propagate new policy changes. Mode-Config also enables the Client or the Remote to have minimal configuration in order to establish the tunnel.
For EZVPN we will have below LAB Build in UNETLAB:
The scenario above shows that EZVPN-Server has DB Server connected to its interface and hosting VPN Connection to both Client and Remote site. We can first proceed with Hub (EZVPN-SERVER and EZVPN-REMOTE) Configuration.
Basic configuration of interface and routing has been already configured and we will focus on EZVPN configuration:
1. Enable AAA For user Authentication and group Authorization
Make sure you don’t lock out console line while configuring AAA:
2. Define Phase 1 negotiation (ISAKMP POLICY):
3. Define VPN Group for Pre-Share exchange:
4. Define Phase 2 IPSEC Policy for Actual Data Encryption:
5. Define Dynamic Map:
6. Define Actual Crypto MAP and apple AAA under Map:
7. Apply Crypto MAP on the Interface where Traffic Actual leaves:
As soon as you apply Crypto MAP under interface your ISAKMP process should be turned ON:
Now we will proceed with Remote site Configuration:
1. Define parameters to connect to the specific EZVPN GROUP on Server:
2. Define inside interface where it will be used or accesses via Easy VPN: (Will be Loopback in our Case)
3. Define Interface where the outgoing connection/traffic is leaving:
NOTE if you get error of XAUTH Request pending, you need to create username and password locally on your router to make it work:
You see as soon as we enter Crypto Map under interface we get logging message that ISAKMP is turned ON:
DB SERVER CLIENT:
Lets move on to the next section which is EZVPN-CLIENT while we use the same topology to connect remote user to EZVPN-SERVER:
For this phase we will not touch other part of the configuration as AAA configuration will remain same so do CRYPTO ISAKMP Policy phase 1.
1. Define and configure AAA (DONE)
2. Define Crypto ISAKMP policy Phase 1 (DONE)
3. Define Address POOL for EZVPN-CLIENT
4. Define Crypto ISAKMP Client Configuration Template:
Make sure you define a new group for EZVPN CLIENT through AAA command syntax.
5. Define Phase 2 Actual data Encryption (DONE)
6. Define dynamic Crypto MAP (DONE) –
NOTE: Make sure you add reverse-route command under the map
7. Define New Crypto MAP (DONE) –
NOTE: Same command syntax will be used you can either use same MAP name or use a new Name: Here in my case:
8. Assign under interface
here in my case since i have 2 CRYPTO MAP i have removed previous crypto MAP from the interface and add new CRYPTO MAP for EZVPN-CLIENT.
10: Client VPN Configuration on PC:
Make sure you disable TRANSPORT OPTION on TAB TRANSPORT and save the profile setup, after that Click on Connect:
When solutions and setups works i believe and more motivated on the scenarios, this is how you should feel the setup, if any network engineer don’t feel Network he/she will not even be able to setup any thing. So let’s dig more on what happened when PC is connected:
You will see that client is connected and have ip address assigned to the interface from the CLIENT-POOL which we assigned on SERVER:
Cool and Perfect let’s move on with the next section which is GET VPN:
Cisco’s Group Encrypted Transport VPN (GET VPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members (GMs) share a common security association (SA), also known as a group SA. This enables GMs to decrypt traffic that was encrypted by any other GM. (Note that IPsec CE acts as a GM.) In GET VPN networks, there is no need to negotiate point-to- point IPsec tunnels between the members of a group, because GET VPN is “tunnel-less.”
The GET VPN solution is based on both open standards and Cisco patented innovative technology which helps utilize the power of underlying MPLS/shared IP networks. In addition to leveraging the existing IKE, IPsec and multicast technologies, GET VPN solution relies on following core building blocks to provide the required functionality:
- GDOI (RFC 3547)
- Key servers (KSs)
- Cooperative (COOP) KSs
- IP tunnel header preservation
- Group security association
- Rekey mechanism
- Time-based anti-replay (TBAR)
Will not get in details of each section and hope you guys got the exact point of what this technology is and where to use it so let’s have some hands-on lab on it:
For this setup we will use below lab build in UNETLAB:
Scenario is that we have 3 Sites in VRF MPLS Cloud named as SITE-A , SITE-B and SITE-C from which SITE-A and SITE-B are GM (Group Member) and SITE-C is KS (Key Server), since this lab will focus on build and setup of GETVPN so we will escape basic routing and MP-BGP with VRF Setups and focus on KS and GM for GET (Group Encrypted Transport VPN):
1. Define ISAKMP POLICY:
2. Define ISAKMP Authentication KEYS for GM:
3. Define IPSEC Parameters for Actual Data Encryption:
4. Create CRYPTO LAB Key for GDOI/REKEY authentication:
KS: our KEY Lab will be named KS
5. Configure GDOI (Group Domain of Interpretation) GROUP:
We use identity unique number of 10 with rekey options and specified ACL to allow traffic. you will see that GDOI is already ON:
6. ACL on KS For Allowing Push authentication to GM:
YOU can either specify specific source or only IP ANY ANY.
Now let’s move on to GM Configuration on SITE-A and SITE-B:
1. Define ISAKMP Policy: (DONE)
2. Define ISAKMP Authentication KEY: (DONE)
3. Define GDOI Group:
4. Define Crypto GDOI MAP:
5. Apply under interface: When you apply GDOI will turn on and REKEY happens:
A site-to-site VPN allows offices in multiple fixed locations to establish secure connections with each other over a public network such as the internet, Site-to-site VPN extends the company’s network, making computer resources from one location available to employees at other locations. An example of a company that needs a site-to-site VPN is a growing corporation with dozens of branch offices around the world.There are two types of site-to-site VPNs:
- Intranet-based — If a company has one or more remote locations that they wish to join in a single private network, they can create an intranet VPN to connect each separate LAN to a single WAN.
- Extranet-based — When a company has a close relationship with another company (such as a partner, supplier or customer), it can build an extranet VPN that connects those companies’ LANs. This extranet VPN allows the companies to work together in a secure, shared network environment while preventing access to their separate Intranets
Following we will illustrate the concept of Site-to-Site VPN on lab diagram where we use Cisco ASA on one side and Cisco IOS on other side, this will contain both configuration types:
Below is the diagram that we will use:
The design above shows that Client VPC4 wants to communicate with Client VPC5, and use the ip addresses shown below:
VPC4: 192.168.10.2/ 24 – 192.168.10.1
VPC5: 192.168.11.2/ 24 – 192.168.11.1
We have our VPC4 connected to the inside interface of ASA1 which is GW for the VPC4, and our ASA1 has default route toward Cloud. We have the same setup on R1 where it acts as GW to VPC5 and it has default route toward Cloud to reach ASA1.
On Site-2-Site VPN you have to reach other end to establish VPN, in our case the cloud could be bunch of routers/paths or anything in the middle. Since the basic IP addressing has already been done, let’s start configuration of Cisco ASA1 for Site-2-Site VPN:
First we configure ISAKMP POLICY for Phase 1 to specify the parameters:
Then we specify parameters for Phase 2 negotiations:
We use AES -256 as our Encryption algorithm and we will have Pre-shared Authentication Key specified later which we use DH group 2 on our example:
Now we specify and establish tunnel-group under Cisco ASA: ( We use “cisco” as pre-shared key which is shown asterisk below)
Now specify access-list to allow certain traffic pass through this connection:
Now we configure our Crypto-MAP to match these parameters and apply/enable it under interface:
This was ASA1 configuration now we will move on to Cisco R1 router to configure the other side for S2S:
First we specify IKEv2 proposal parameters and then match them under IKEv2 Policy:
Now we will specify Key with Peer and bind them under IKEv2 Profile:
In above we match the peering point of the ASA1 interface and then specify our pre-share key “cisco”. now we need to specify our ACL to allow traffic and then match them under Crypto MAP:
In above you see when we applied the Crypto map under interface he Crypto ISAKMP is ON and we can start testing, for test we will use below commands:
# show crypto engine connection active
# clear crypto session
# PING > SOURCE > DESTINATION
Your end to end Ping should be successful and you should get desired result:
I think this is more than enough for any candidate to learn and practice CCIE Security Labs and it is time for me to get back to my lab..