Strong encryption is the most important important aspect to ensuring data confidentiality when it is in transit across a network. Various protocols for transport level encryption exist. A couple of the more commonly cited ones are Secure Sockets Layer (SSL)/Transport Layer Security (TLS) and IP Security (IPSec).
SSL and TLS are common for websites, file transfers, and other application level services while IPSec is typically used to encrypt all traffic (or potentially a subset) between two or more endpoints (node-node IPSec), two or more gateways (gateway-gateway IPSec), and between oner or more nodes and one or more gateways (node-gateway IPSec).
In this example, I will configure IPSec encryption between two "trusted" networks over a network that is "untrusted." Assume that we have the following topology:
To begin, we need a plan...
Traffic originating from 192.168.1.0/24 and traveling across T1's fa0/0 interface to 192.168.2.0 should be encrypted. Traffic from 192.168.2.0/24 to 192.168.1.0/24 should also be encrypted (note that it is possible to encrypt asymmetrically, but not recommended). In this case, we are looking for security over performance, so we will use AES encryption (vs 3DES or DES, which are considered weak).
To begin, let's configure suitable policies on T1 and T2:
! Define a new internet security association key management protocol (ISAKMP) policy
crypto isakmp policy 1
! Use AES encryption
encryption aes
! Define pre-shared keys, as opposed to certificate based authentication/exchange
authentication pre-share
! Diffie-Hellman group 2 - more secure than group 1, but also more CPU intensive
group 2
! Specify the key lifetime (time until renegotiation)
lifetime 600
! Define a shared key for encrypting traffic between T1 and T2. Use password 'mypasswd'
crypto isakmp key mypasswd address 1.1.1.6
Now for the configuration on T2 (similar to T1, but with different peer address):
!
crypto isakmp policy 1
encryption aes
authentication pre-share
group 2
lifetime 600
crypto isakmp key mypasswd address 1.1.1.2
!
Now, we want to define the transform set. For the c3725 Series routers running IOS 12.4, we can define up to three transforms + compression. In this case, we'll define an authentication header (AH) and the AES ESP.
On T1:
crypto ipsec transform-set T2 ah-sha-hmac esp-aes
On T2:
crypto ipsec transform-set T1 ah-sha-hmac esp-aes
Note that using AH without ESP does not encrypt the packet, where it is possible to encrypt the packet using ESP without using the authentication header (AH). Combining AH and ESP encapsulates and encrypts the entire packet as we can see from the packet capture further below.
After we have the ISAKMP Policy and the transform set defined, we want to define ACLs and a crypto map that define which traffic flows need to be encrypted. The crypto map entries are fairly straightforward, defining the peer address for encryption/decryption, the transform set do be used, and the extended ACLs that define which traffic should be encrypted.
Below are the extended ACLs for matching traffic to be encrypted:
On T1:
! Match traffic originating from 192.168.1.0/24 going to 192.168.2.0/24
access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
On T2:
! Match traffic originating from 192.168.2.0/24 going to 192.168.1.0/24
access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
And now for the specific crypto map entries:
On T1:
crypto map T2 10 ipsec-isakmp
set peer 1.1.1.6
set transform-set T2
match address 101
On T2:
crypto map T1 10 ipsec-isakmp
set peer 1.1.1.2
set transform-set T1
match address 101
Now we have all of the pieces in place for IPsec. We now need to assign the crypto map to the outgoing interfaces.
On T1:
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.252
duplex auto
speed auto
crypto map T2
!
On T2:
!
interface FastEthernet0/0
ip address 1.1.1.6 255.255.255.252
duplex auto
speed auto
crypto map T1
!
To verify the setup, we can send packets that need to be encrypted (in this case using the IOS extended ping utility). The first ping may time out because of the security association negotiation that needs to occur:
T1#ping 192.168.2.1 source Lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 104/105/108 ms
We now look at whether we have an SA:
T1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
1.1.1.6 1.1.1.2 QM_IDLE 1007 0 ACTIVE
T1#show crypto isakmp sa detail
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.
1007 1.1.1.2 1.1.1.6 ACTIVE aes sha psk 2 00:07:21
Engine-id:Conn-id = SW:7
And we can perform further verification with a packet capture that shows encapsulated/encrypted traffic:
See Also:
The Road to the CCIE
No comments:
Post a Comment