I'm back in the saddle again and this time it is with security. My job role has changed where I now do more security, pre sales and implementation. As a Solutions Integration Architect, I design and deploy solutions for customers. Because of the role and focus shift, Security is where I spend my time now. I currently have a CCNA in Security that I earned back in 2013, it's dated and I'm beginning the process of upgrading it to the current standard 210-260 IINS. I won't take the exam, but I will re-learn what I have forgotten and add to what I didn't already know.
IOS to IOS site to site VPNs with crypto maps secured with pre-shared-keys are a very common solution used today by companies all over the world. Very simple in the grand scheme to configure and verify. Our demonstration will consist of 2 CSR1000v's and 2 Windows 7 Pro VMs running in ESXi 6.0. The goal is to setup a VPN on the CSRs to allow the 2 Windows 7 VMs to communicate with each other. Sec-PC1 and Sec-PC4 will be our test devices. I already have this solution working, I will be copying and pasting the working configurations here. R1 and R4 do have reachability with each other, but I will prove this works with a couple of ping/traceroute outputs.
\
R1#ping 10.2.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/20 ms
R4#ping 10.1.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/20 ms
Since we will be using IKEv1/ISAKMP with pre-shared-keys, the configuration will be relatively basic.
R1's configuration
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 2
crypto isakmp key cisco address 10.2.4.4
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
mode tunnel
crypto map CMAP 1 ipsec-isakmp
set peer 10.2.4.4
set transform-set TSET
match address ACL
crypto map CMAP
!
ip access-list extended ACL
permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
!
interface GigabitEthernet1.11
crypto map CMAP
R4's configuration
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.10
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
mode tunnel
crypto map CMAP 1 ipsec-isakmp
set peer 10.1.1.10
set transform-set TSET
match address ACL
crypto map CMAP
!
ip access-list extended ACL
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255
!
interface GigabitEthernet1.24
encapsulation dot1Q 24
ip address 10.2.4.4 255.255.255.0
crypto map CMAP
Let's breakdown the crypto, access-list and crypto map configuration and understand what is happening. The "isakmp" policy is considered the "phase 1" portion of the VPN, this is configured so that the VPN endpoints each have identical configurations and those configurations are used to prove the endpoints are who they say they are. This is essentially the "control-plane" for VPNs. The ISAKMP policy identifies the "policies" that each endpoint must agree on, if no agreement is found, Phase 1 fails. The "isakmp key" is the private key exchanged between VPN peers used to authenticate each other. The "key cisco" is the actual private key, the address is the remote end of the VPN endpoint.
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.10
This portion is the "phase 2" portion of the crypto configuration or the data plane. this identifies the encryption protocol used to protect the data.
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
mode tunnel
The access-list called ACL is also referred to as the "proxy acl" which basically means, any traffic that is matched in this ACL will be encrypted and sent over the VPN. It is required to match on interesting traffic, it is a data plane filter. The remote end swaps the source and destination, so 192.168.4.0/24 and 192.168.1.0/24 are reversed so that return traffic is appropriately matched.
ip access-list extended ACL
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255
The crypto map is what "glues" all of this together, it is identified by the ipsec-isakmp, it sets the remote VPN peer, identifies the encryption protocol and uses the ACL to identify what traffic is to be encrypted.
crypto map CMAP 1 ipsec-isakmp
set peer 10.1.1.10
set transform-set TSET
match address ACL
Now we have to apply the crypto map the outgoing interface. The crypto map can be applied to many outside interfaces, in this case, only one is needed. Once this is applied, there is a syslog generated identifying that ISAKMP is now enabled
interface GigabitEthernet1.24
crypto map CMAP
R4(config-subif)#crypto map CMAP
R4(config-subif)#exit
R4(config)#i
.Jul 24 01:05:17.161: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
Now, the reason you have read this far, is it actually working? Here is how you verify Phase 1 and Phase 2. The phase 1 shows that R1 and R4 have an active "QM_IDLE" connection, QM being quick mode, ISAKMP SA is authenticated and can be used for subsequent Quick Mode (Phase 2) exchanges. This indicates that the bidirectional ISAKMP connection is up and the VPN endpoints are successfully authenticated
Phase 1
R4#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.1.1.10 10.2.4.4 QM_IDLE 1004 ACTIVE
Phase 2 is the actual data plane, the thing to look for, bolded, is the pkts encrypt and decrypt. This indicates that the unidirectional SA are both sending and receiving traffic.
Phase 2
R4#show crypto ipsec sa
interface: GigabitEthernet1.24
Crypto map tag: CMAP, local addr 10.2.4.4
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer 10.1.1.10 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 259105, #pkts encrypt: 259105, #pkts digest: 259105
#pkts decaps: 244184, #pkts decrypt: 244184, #pkts verify: 244184
#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.2.4.4, remote crypto endpt.: 10.1.1.10
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1.24
current outbound spi: 0x14644456(342115414)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x9935538F(2570408847)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2047, flow_id: CSR:47, sibling_flags FFFFFFFF80000048, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4607554/1027)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x14644456(342115414)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2048, flow_id: CSR:48, sibling_flags FFFFFFFF80000048, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4607309/1027)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
Proof from the Windows 7 VMs
This is from Sec-PC1 RDPd into Sec-PC4 where Sec-PC4 is pinging Sec-PC1 repeatedly.
This is from Sec-PC1 ping Sec-PC4 repeatedly.
Thanks for stopping by!
Rob Riker, CCIE #50693, CCNA Security
