So it doesn’t really use retsyn, but it does use certs! Get it? Certs…retsyn…
But I digress.
In my award-seeking earlier post, I discussed how to setup a CA server with an IOS router. I then enrolled two additional routers with the CA server and they now have signed certificates. Those very certificates can now be put to use by creating an EzVPN connection using those very certificates rather than pre-shared keys for authentication. First, though, the obligatory lab diagram:
Here, R2 is going to connect to R3. R2 is going to be the EzVPN client, and R3 is going to be the EzVPN server. But what about that puffy little cloud? That is a connection to a Windows XP box that is running the Cisco IPSec Client. The IPSec client is going to enroll with the CA Server (R1) and connect to R3 as a remote connection. A little cheating must be done, however. R3 can directly connect to the XP machine, and because we have OSPF running, the XP machine will be able to connect to everything off the bat. In order to test, a ping will be sent from the loopback of R1 to the IP address assigned to the VPN from the VPN pool.
So why use EzVPN? On an IOS router, EzVPN allows a remote IPSec client, whether it is an ASA, router, or the Cisco IPSec VPN Client to connect “on the fly” to the EzVPN server. This doesn’t make much sense with most site-to-site VPN connections with routers, where other L2L connections, such as VTI, DMVPN, or GET VPN can be used. It also doesn’t scale well with a very large internal environment. For users on the road, however, this allows a connection to the network from nearly anywhere. Also, for home users that have a DHCP address assigned by their broadband ISP, they can use a small router or a small ASA to connect as a client when connectivity is needed to the main office. Keep the following in mind: If the customer is a large company that has many remote users, then using an IOS router is not the best bet for remote users. In such a case, and ASA device provides a much more feature-rich solution. But, for the small office that has maybe a couple of workers that needs remote access, this could do. And it must do for passing the CCIE:Security lab. So we do.
There are multple ways to setup the EzVPN server. The example here will focus on using a DVTI. Why DVTI? DVTI are virtual dynamic tunnels that are similar to VTI tunnels, so they offer the benefits of VTI, such as the sending of routing protocols, configuration of policy, and determining encrypted traffic through routing rather than by interface. The biggest benefit is that it sets a static route in the table that can then be redistributed through any IGP, which allows the entire network to know the new connection “on the fly”. This is done by configuring a Virtual Template that is then cloned for each new connection created by various EzVPN clients.
Here are the steps for creating the EzVPN server:
- Turn on AAA.
- Define the ISAKMP policy.
- Create a local username/password. A RADIUS or TACACS+ server can also be used, but this example will use a local username.
- Set the crypto identity to use distinguished names (DN). This is needed for certificates in our example.
- Create the ISAKMP client configuration group.
- Create the ISAKMP profile.
- Create an IPSec transform set.
- Create an IPSec profile.
- Configure the Virtual-Template interface.
- Configure an local pool of addresses for the VPN.
- Configure an access-list for a split tunnel (optional).
And that’s it! Uh…yeah…
In our example, R3 is the server, so the following is configured on R3. I am going to put all the steps in at once:
aaa new-model ! ! aaa authentication login VPN local aaa authorization network VPN local ! username ccie password 0 ccie ! crypto isakmp policy 10 encr aes group 2 crypto isakmp identity dn ! crypto isakmp client configuration group VPN_GROUP key cisco dns 192.168.1.1 domain kidvelvet.local pool VPN_POOL acl VPN_SPLIT_TUNNEL save-password split-dns kidvelvet.local crypto isakmp profile VPN_PROFILE match identity group VPN_GROUP client authentication list VPN isakmp authorization list VPN client configuration address respond virtual-template 1 ! ! crypto ipsec transform-set STRONG esp-aes esp-sha-hmac ! crypto ipsec profile IPSEC_PROFILE set transform-set STRONG set isakmp-profile VPN_PROFILE ! interface Virtual-Template1 type tunnel ip unnumbered FastEthernet1/0 tunnel source FastEthernet1/0 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC_PROFILE ! ip local pool VPN_POOL 172.31.255.1 172.31.255.254 ! ip access-list extended VPN_SPLIT_TUNNEL permit ip 192.168.0.0 0.0.255.255 any permit ip 192.168.1.1 0.0.0.0 any permit ip 192.168.2.2 0.0.0.0 any permit ip 192.168.3.3 0.0.0.0 any
Take notice at the Virtual-Template in the ISAKMP profile. While the order shown is the order that is in the router configuration file, if you do not configure the Virtual Template before adding it to the ISAKMP profile, a rejection will occur, saying that it isn’t configured. And while I am on the subject of configuring the Virtual-Template, make sure that the type tunnel is specified at the end. I accidentally created a Virtual-Template without doing the type tunnel, and I was unable to remove the Virtual-Template. The only recourse to remove the interface was to reboot the router. Not good. Time is valuable in the CCIE lab, and rebooting routers is not one of the best ways to spend it.
The save-password option is needed for the client to connect properly. Otherwise, other IOS routers will not be able to use a configured password to connect. Again…not good.
I also had to change the split tunnel to add specific routes. Why? OSPF is also advertising specific routes. If the routes are less specific than the routing protocol, then the routing protocol will win the longest match first battle royale. This means that the original traffic will not be encrypted across the tunnel, but the return traffic will be. That’s not what we want. In a production environment, we would simply add the VPN network as another network on the router and then advertise. But playing around in a lab may not always lead to best practice. I know the CCIE lab doesn’t always ask to follow best practice. 
Finally, the key option is needed only for non-certificate configurations. It is left over from some previous testing. But if EzVPN is configured with pre-shared keys, then this line is necessary.
I made the VPN local pool unique to the network. Each router interface uses the 10.10.<vlan>.<router number> IP scheme. Each loopback uses a 192.168.<router number>.<router number> IP scheme. So, the 172.16 block of private IP addresses will distinguish this traffic as being VPN traffic. By using the split tunnel, I am only encrypting traffic going from the VPN to the loopbacks, but not to the interfaces. This will be crucial in testing.
The EzVPN client for IOS is much simpler. Here are the steps:
- Create the ISAKMP policy.
- Set the ISAKMP identity to DN.
- Create the IPSEC client profile.
- Create the virtual template.
- Apply the client to an outside and inside interface.
MUCH easier!
So remember when I made those certificates in that past blog post? Well, that certificate isn’t going to work. The reason? When connecting to an EzVPN server, the VPN client needs to somehow identify with the VPN group that it will attach. A server can contain multiple tunnel groups, and each one will have a different group name. When using a pre-shared key, this can be done by listing the group in the client and then listing the key after the group name. However, a certificate is being used instead of a key. In order to associate the certificate with a key, there needs to be something in the certificate that identifies the group name. That would be the OU, or Organizational Unit. You put the group name in the OU when associating with the trustpoint, and that will associate with the proper EzVPN group profile.
Because the certificate was already downloaded, we need to remove it. This is done by removing the trustpoint. A second trustpoint could be created, but let’s not muddle up the configuration on the router. So to remove the trustpoint:
R2(config)#no crypto ca trustpoint kidvelvet % Removing an enrolled trustpoint will destroy all certificates received from the related Certificate Authority. Are you sure you want to do this? [yes/no]: yes % Be sure to ask the CA administrator to revoke your certificates. R2(config)#
And the trustpoint and certificates are now gone. So let’s create a new trustpoint with the proper OU. The group on R3 is called VPN_GROUP, so we will create a trustpoint that has the OU=VPN_GROUP attached to it.
R2(config)#crypto pki trustpoint kidvelvet R2(ca-trustpoint)# enrollment url http://10.10.10.1:80 R2(ca-trustpoint)# subject-name OU=VPN_GROUP R2(ca-trustpoint)# revocation-check none R2(ca-trustpoint)#exit R2(config)#
Now authenticate against R1 and enroll:
R2(config)#crypto ca authent kidvelvet Certificate has the following attributes: Fingerprint MD5: 393B5E2E 740B2173 411BBCC2 BE9B9955 Fingerprint SHA1: 17501051 B95BF739 39B7A116 8A12B7A3 EFC9B5E9 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. R2(config)#crypto ca enroll kidvelvet % % 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: OU=VPN_GROUP % The subject name in the certificate will include: R2.kidvelvet.local % 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 ca certificate kidvelvet verbose' commandwill show the fingerprint. R2(config)# Feb 16 23:54:59.291: CRYPTO_PKI: Certificate Request Fingerprint MD5: 3A1A1955 4F193A09 1F136673 F48F1B4C Feb 16 23:54:59.299: CRYPTO_PKI: Certificate Request Fingerprint SHA1: F2725BDF 8C195B48 253B39CE 979A4FD1 DFEE69CC R2(config)# Feb 16 23:55:01.451: %PKI-6-CERTRET: Certificate received from Certificate Authority R2(config)#
Note that the certificate was automatically enrolled. I added the grant auto command to the pki server. This is needed for when we enroll the IPSec Client on the XP box.
Now the rest of the configuration:
crypto isakmp policy 10 encr aes group 2 crypto isakmp identity dn ! ! ! ! ! crypto ipsec client ezvpn EZVPN connect auto mode client peer 10.10.30.3 virtual-interface 1 username ccie password ccie xauth userid mode local ! interface FastEthernet0/0 ip address 10.10.20.2 255.255.255.0 speed 100 full-duplex crypto ipsec client ezvpn EZVPN ! interface FastEthernet0/1 ip address 10.10.40.2 255.255.255.0 ip dns view-group ezvpn-internal-viewlist duplex auto speed auto crypto ipsec client ezvpn EZVPN inside ! interface Virtual-Template1 type tunnel ip unnumbered FastEthernet0/0 tunnel mode ipsec ipv4
The client is now installed. Briefly after installing the client, some output will appear that will show the client is active:
R2(config)# Feb 17 00:12:27.177: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client) User=ccie Group= Server_public_addr=10.10.30.3 Assigned_client_addr=172.31.255.64 R2(config)# Feb 17 00:12:27.241: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up Feb 17 00:12:27.829: %LINK-3-UPDOWN: Interface Loopback10000, changed state to up Feb 17 00:12:28.241: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
This tells us that the client is up, it has been assigned the IP address of 172.31.255.64 from the pool, and a couple of new interfaces have appeared. The Virtual-Access2 interface is the actual DVTI, and the loopback10000 interface is assigned the 172.31.255.64 address. Hmm…sounds like things are working. Verification is in order:
R2#sh crypto isakmp sa det Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1018 10.10.20.2 10.10.30.3 ACTIVE aes sha rsig 2 23:54:27 CX Engine-id:Conn-id = SW:18 IPv6 Crypto ISAKMP SA R2#
The key here is the ACTIVE state, with the aes encryption, sha hash, and rsig for authentication. The rsig means that the certificate is being properly used. Now the routes:
R2#sh ip route Codes: 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 Gateway of last resort is not set 172.31.0.0/32 is subnetted, 1 subnets C 172.31.255.64 is directly connected, Loopback10000 10.0.0.0/24 is subnetted, 4 subnets O 10.10.10.0 [110/20] via 10.10.20.3, 20:52:19, FastEthernet0/0 C 10.10.20.0 is directly connected, FastEthernet0/0 O 10.10.30.0 [110/20] via 10.10.20.3, 20:52:19, FastEthernet0/0 C 10.10.40.0 is directly connected, FastEthernet0/1 192.168.22.0/32 is subnetted, 1 subnets C 192.168.22.2 is directly connected, Loopback10 192.168.1.0/32 is subnetted, 1 subnets S 192.168.1.1 [1/0] via 0.0.0.0, Virtual-Access2 192.168.2.0/32 is subnetted, 1 subnets C 192.168.2.2 is directly connected, Loopback0 192.168.3.0/32 is subnetted, 1 subnets S 192.168.3.3 [1/0] via 0.0.0.0, Virtual-Access2 S 192.168.0.0/16 [1/0] via 0.0.0.0, Virtual-Access2 R2#
Routes have been added statically that use the Virtual-Access2 interface. Nice! After a ping test to 192.168.1.1, we see the following IPSec traffic:
R2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/91/224 ms
R2#sh crypto ipsec sa
interface: Virtual-Access2
Crypto map tag: Virtual-Access2-head-0, local addr 10.10.20.2
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.10.30.3 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7
#pkts decaps: 61, #pkts decrypt: 61, #pkts verify: 61
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.10.20.2, remote crypto endpt.: 10.10.30.3
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xA4DE3E5B(2766028379)
inbound esp sas:
spi: 0x4C64298A(1281632650)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 103, flow_id: SW:103, crypto map: Virtual-Access2-head-0
sa timing: remaining key lifetime (k/sec): (4555185/3075)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xA4DE3E5B(2766028379)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 104, flow_id: SW:104, crypto map: Virtual-Access2-head-0
sa timing: remaining key lifetime (k/sec): (4555192/3075)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
R2#
Verification is complete. Traffic is being encrypted and decrypted. Now on to the puffy cloud…er, XP machine. Ok, I think that is going to be saved for an additional post…
Good luck!
