Lab VPN
Lab VPN
Objectives
Configure L3 (IP-in-IP) VPN between two sites
Understand IPSec options and phase 1 and phase 2 negociations
Topology
Guest hosts
VPC1 (192.168.1.2/24 gateway 192.168.2.1)
VPC2 (192.168.2.2/24 gateway 192.168.2.1)
VPC3 (192.168.3.2/24 gateway 192.168.3.1)
Routers
Router1
f0/1 192.168.1.1
f0/0 10.0.1.1
Router2
f0/1 192.168.2.1
f0/0 10.0.2.1
Router3, Router4, Router5 (the Internet)
various subnets
RIP dynamic routing for routes propagation
Mission#0:
1. activate traffic logging between Router1 and Router4. Ping from PC1 to PC3 and
validate that the traffic is in clear.
2. do likewise for a ping between PC1 and PC2. Monitor on the branch between Router1
and Router4. The traffic is in clear.
In practice, several other options are available, depending on the hardware/software you will
have at hand (CISCO, Juniper, Palo Alto, Huawei,... ).
In practice, a VPN induces a loss of throughput of ~25% due to overheads, processing, etc.
This is why some implementation are hardware accelerated by means of cryptoprocessors in
the equipment (e.g. AES is often found). These side processors are also available in
commodity equipments (e.g. Apple computers, INTEL processors, ...)
IKE exists only to establish a SAs (Security Association) between two IPsec end points.
Remember that IPSec allows to have specific parameters for each pair of source and
destination.
As a first step, IKE negotiates a SA (an ISAKMP SA) relationship with the peer by
authenticating. This is reflected by means of a ISAKMP Phase 1 policy:
Note that the policy is not (yet) related to a specific peer. It describes what parameters are in
use fro the encryption, HMAC, key exchange, etc... Several policies can be described and
they will be tried one by one to initiate the VPN tunnel (until one actually works with the
remote peer).
In a second step, let us now set the pre-shared password ("unicorn") for our destination
All parameters for Phase 1 are now set. What happens in phase 1 ? Well, when detecting a
packet subject to crypto transformation (see below), the destination is looked up. Then, the
passord (or certficate) for that destination is retrieved from the local database. Next, each
policy is used (one after one) to try to establish a Phase 1 with the remote peer. When one is
accepted a SA (IPSec security assiciation) is created.
Create extended ACL (access control lits) to determine what packets are subject (or
not) to transformation. This allows to separate between the normal traffic and the VPN
traffic.
Create IPSec Transform to configure how packets will be ciphered, MAC'ed, etc..
Create Crypto Map to link a specific destination with a specific transform and filtered
with the ACL (it is a glue of the previous steps)
Apply crypto map to the public interface to tell the router to analyze every packet
passing by that interface for a possible crypto transformation.
Now let us implement each of the above steps in the CISCO routers: - Create extended ACL
-- First step is to create an access-list and define the traffic we would like the router to pass
through the VPN tunnel. In this example, it would be traffic from one network to the other,
10.10.10.0/24 to 20.20.20.0/24. Access-lists that define VPN traffic are sometimes called
crypto access-list or interesting traffic access-list (note the wildcard notation 0.0.0.255
which is the bit-invert notation of netmask for the matching).
The traffic from 192.168.1.0/24 to 192.168.2.0/24 will be subject to tagging and processing in
the pipeline called "VPN-TRAFFIC" (you can put here any name you like....)
Create IPSec Transform -- There are defined the mode (AH or ESP) and the ciphering
parameters.
A transformation set is prepared and can be applied to the packets. Nothing special here.
Create Crypto Map -- The Crypto map is the last step of our setup and connects the
previously defined ISAKMP and IPSec configuration together:
R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 10.0.2.1
R1(config-crypto-map)# set transform-set MYTS
R1(config-crypto-map)# match address VPN-TRAFFIC
The crypto map bundles everything. It tells to follow these steps for each packet: 1. if a
packets is tagged as VPN-TRAFFIC 1. apply the transformation MYTS (ciphering, MAC'ing)
1. send it to the tunnel endpoint 10.0.2.1 Note that this last step will trigger the Phase 1 to
autenticate and negotiate a session key between the two tunnel peers (everything makes
sense now).
Finally, we must apply the crypto map to a (or several) network interface
This simply means that any packet flowing in this interface will be inspected as per the rules
defined in the crypto map CMAP.
One last word: this must obviously be configured on both ends of the tunnel.
Mission 3: Validate
PC1#ping 192.168.3.2
interface: FastEthernet0/0
Crypto map tag: CMAP, local addr 10.0.1.1
inbound ah sas:
outbound ah sas: