Entries Tagged as 'VPN'

IPSec over GRE and IPSec VTI

When reviewing the topic of IPSEC over GRE Tunnel, I have observed that we have several ways to implement it. However, some posts are confusing people. For example, this post is named IPSEC over GRE Tunnel, the actual configuration is IPSec static VTI (Virtual Tunnel Interface), because the configuration under tunnel interface has one line, which indicated that the tunnel mode is changed.

tunnel mode ipsec ipv4

So, in this post, I would like to clarify some misunderstanding.

GRE as IPSec interested traffic

This is the first, and probably less-used solution for IPSec over GRE. We setup Lan-to-Lan IPSec between two physical interface of two routers. Under the crypto map, we set the interested traffic as

access-list 105 permit gre <tunnel_source_ip> <tunnel_source_mask> <tunnel_des_ip> <tunnel_des_mask>

After ping traffic between each end of the tunnel, the IPSec tunnel is setup. The following are the basic configuration of two routers.

R1

!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp key CISCO address 150.1.12.2
!
!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
!
crypto map CRYPTO_MAP 10 ipsec-isakmp
set peer 150.1.12.2
set transform-set R1_TO_R2
match address 105
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
crypto map CRYPTO_MAP
!
access-list 105 permit gre 150.1.12.0 0.0.0.255 150.1.12.0 0.0.0.255
!

R2

!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp key CISCO address 150.1.12.1
!
!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
!
crypto map CRYPTO_MAP 10 ipsec-isakmp
set peer 150.1.12.1
set transform-set R2_TO_R1
match address 105
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
crypto map CRYPTO_MAP
!
access-list 105 permit gre 150.1.12.0 0.0.0.255 150.1.12.0 0.0.0.255
!

GRE Tunnel Protection

Since we use tunnel protection command under tunnel interface, we don’t need to define crypto map, instead, we need to define ipsec profile. Then, we need apply ipsec protection profile to the tunnel interface. The following are the basic configuration. Please note that, there is no “tunnel mode ipsec ipv4” command, which means, the tunnel mode is still GRE.

R1

!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
tunnel protection ipsec profile TEST
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
!

R2

!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
tunnel protection ipsec profile TEST
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
!

Removing 4-Bytes GRE header ???

Cisco brought us IPSec VTI (virtual tunnel interface) in IOS 12.3T. The purpose of that is to have a new tunnel mode to reduce 4 bytes GRE header in the traffic. However, different tunnel mode can apply different application. Here are some considerations for IPSec VTI. The IPsec VTI is limited to IP unicast and multicast traffic only, as opposed to GRE tunnels, which have a wider application for IPsec implementation. Thus, for some non-IP traffic, we still need IPSec over GRE.

R1

!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
tunnel protection ipsec profile TEST
tunnel mode ipsec ipv4
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
!

R2

!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
tunnel protection ipsec profile TEST
tunnel mode ipsec ipv4
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
!

ezRemeber ezVPN Configuration

When playing around Easy VPN server configuration, I felt it’s not straight forward to remember, especially from Cisco configuration guide. Later, I figured it out the way to remember those complicated configuration and very glad to share in here. Basically, the configuration is divided to 6 parts.

  1. Phase 1
  2. Phase 1.5
  3. Phase 2
  4. Dynamic-mapping
  5. Crypto-mapping
  6. Apply to the interface

Phase 1

IPSec Phase I configuration is the same as Lan to Lan (L2L) IPSec configuration. We need to define four basic parameters for crypto isakmp policy.

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

Compared to LAN to LAN IPSec, the ezVPN pre-shared key is defined in easy VPN group. The group name is ID and the pre-shared key is configured under the group settings using the command key <STRING>.

!
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL
!

However, I prefer to configure ezVPN group on Phase 1.5.

Phase 1.5

This so called phase 1.5 implements the special ISAKMP which allows the VPN client requests certain attribute values. Unlike L2L IPSec, which peers are specifically defined, the ezVPN client needs ezVPN Server to tell the attributes that clients request, such as IP address (pool), DNS Server, Split Tunnel and pre-shared key.

!
ip local pool EZVPN 172.22.0.1 172.22.0.254
!
ip access-list extended SPLIT_TUNNEL
permit ip 172.17.94.0 0.0.0.255 any
!
crypto isakmp client configuration address-pool local EZVPN
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL

Note that the per-shared key is only for Phase 1 authentication. Phase 1.5 still need authentication. ISAKMP configuration mode allows for Extended Authentication (Xauth) after the ISAKMP SA has been established. The Xauth is basically refer to AAA list in IOS.

aaa new-model
!
!
aaa authentication login CONSOLE none
aaa authentication login EZVPN local
aaa authorization network EZVPN local
!
username CISCO password 0 CISCO
!
crypto map VPN client authentication list EZVPN
crypto map VPN isakmp authorization list EZVPN

It’s interesting for me that the client authentication and isakmp authorization are actually happened on Phase 1.5, but the configuration is on the final crypto mapping.

Phase 2

The configuration is the same as L2L IPSec.

!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac

Dynamic Mapping

Before mapping crypto to isakmp-ipsec, we should create a dyanmic mapping to accept connections from any remote peer. This part is different with L2L IPSec which specify the peer address by match address <PEER ADDRESS>.

!
crypto dynamic-map DYNAMIC 10
set transform-set 3DES_MD5
reverse-route

To let router has knowledge of the remote end-point, it must has a route on the routing table for the end-point. After issuing reverse-route command, when ezVPN session is up, there is a static route stored in the routing table. To let the other routers has knowledge of ezVPN client, we can simply redistribute static to some dynamic routing protocal such as EIGRP or OSPF.

CRYPTO Mapping

We have defined two lines crypto mapping for authorization and authentication. We need finalize all crypto mappings. Let me summarize what crypto mapping does:

  1. client authentication and isakmp authorization.
  2. client address response.
  3. ipsec-isakmp dynamic mapping.

!
crypto map VPN client configuration address respond
crypto map VPN 10 ipsec-isakmp dynamic DYNAMIC

Apply to the Interface

!
interface FastEthernet0/0
crypto map VPN