Here you are very typical architecture. Local Internet access and site to site VPN at the same router – easy case. To deploy this kind of configuration almost always we have to engage IPSec VPN and NAT at one platform. What does NAT imply for IPSec – let’s answer this question.

First we have to take a look at Cisco IOS order of operations. NAT is before encryption, what is means that traffic that needs to be encrypted will be first NATed then encypted. Mostly our crypto ACL that defines interesting traffic for encyption matches our source inside LAN subnet and remote end subnet IP. Once we add default NAT configuration, IPSec will not work properly. Traffic will never match crypto ACL because first will be translated and source IP will change (depends on NAT configuration) to outside interface IP or to dynamic IP defined in NAT pool.

To resolve this issue we have to exclude traffic that needs to be encrypted from NAT translation. Here you are quick configuration example how to proceed.


Traffic from subnet to needs to be encrypted. Remaining traffic from to Internet needs to be translated to outside interface IP.


Define two ACLs. First needs to match VPN traffic (you can leverage of course crypto ACL that is already used by IPSec crypto map), second will define NAT traffic. Then create route map with two statements, in first statement we have to use deny key word and match crypto ACL, second permit statement will match NAT ACL. Route map has to be assigned under to ip nat inside configuration that describes traffic that will be translated. That’s all. Here you are how it looks like from configuration perspective.

ip access-list extended NAT
permit ip any
ip access-list extended VPN
permit ip
route-map NAT deny 10
match ip address VPN
route-map NAT permit 20
match ip address NAT
ip nat inside source route-map NAT interface FastEthernet0/0 overload
interface FastEthernet0/0
ip nat outside
crypto map MAPA

, ,

Is it a issue to achive proper QoS for IP tunneled traffic over GRE encrypted by IPsec tunnel – for Cisco router is not the case. With use of GRE/IPsec ToS byte is copied from the original IP header to the new GRE and IPsec IP headers. It’s done by default without any specific configuration, this process is called the “ToS Byte Preservation” feature.
For example if router gets IP packet with DSCP value equal to 46 then packet is encapsulated in to GRE header, ToS byte is copied to the GRE IP header ToS field. In case this GRE packet is subject to IPsec encryption the same process occurs and ToS byte from GRE headers is copied into IPsec IP header – all is done by automatically. But what if QoS policy would classify and do action based on original source IP and specific TCP or UDP port. Solution is the QoS pre-classify feature. It allows router to temporarily copy and store the layer 3 and 4 headers from the original IP packet and take action based on these values so classify, queue and schedule on the router’s egress interface accordingly.

To achive above QoS feature have to be enabled both under GRE tunnel and IPsec crypto map as follows:
Router(config)#int tun 0
Router(config-if)#qos pre-classify
Router(config)#crypto map MAPA 100 ipsec-isakmp
Router(config-crypto-map)#qos pre-classify

Now you are ready to go with class-map and policy-map. Remember that in this case policy needs to be assigned to physical interface where crypto map is configured already.

, , , , , ,

Ping tool is very usful to discover or understand some network behaviours related to network protocols or services that are run on Cisco routers or MS Windows. Before we start with ping test, first of all we have to know how this tool has been deployed in both systems.

Datagram/Packet size (IP Total Length field) = IP Header + Payload
As name imply it’s datagram/packet size so IP Header + Payload.

With Cisco IOS the case is simple. In below example packet size is equal to 1000 bytes, it means that ICMP Echo ping message will be generated with standard 20 bytes for IP Header + 980 for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 972B).

R1#ping repeat 1 size 1000
Type escape sequence to abort.
Sending 1, 1000-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms

In case of Windows OS it’s more complicated. We can define specific data size (don’t mix up it with payload) so in this example 1000B means exactly ICMP data in payload + fields in ICMP + IP Header. In this case IP packet size will have 20 bytes for IP Header + 1008 bytes for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 1000B). So in case of Ethernet network frame will have 1042B (14B Ethernet II Header included). 

C:\>ping -l 1000 -n 1

Here you can find sniff of ICMP echo request based on the Windows ping tool.

To recap:
Cisco ping size = total IP packet length
Windows ping size = just ICMP data without ICMP 8B fields like type, code, checksum, identifier and sequence.

Fragmentation and Maximum Transmission Unit (MTU)

For IP protocol MTU defines size of IP packet (so IP Total Length field) can can be send thru network device interface. As packets are encapsulated into frame in data link layer they have to be small enough to be transmited by the physical transmission technology.  In case packet is larger then maximum size of underlying network technology there is need to divide an IP packet in to smaller IP chunks. This process is called as IP fragmentation, puttin chunks all together back on the second end of the transmission is called as reassemble, the reassemble of IP packets is done on the IP destination end.

Fragmentation issues

Fragmentation couse more overhead for the receiver then to sender. Device responsible for fragmentation needs to create new header and devide orignal pacekts into fragments. From the other side receivermust allocate memeory to properly serve all fragments and consolidate them all togther. It is not a issue for final destinatio like a host but could couse a problem for routers.

Several issues related to IP fragmentation that couse that is should be avoided:

  • Requires the support of slow path processing on the routers and additionaly use CPU of the receiver part  to reassemble the fragments (forwarding functions is done by software so process switched). 
  • In case router gets fragmented needs to do IP reassembling it reserve the largest buffer available with which to work because it has no idea what size of the original IP packet will be get.
  • If one fragment of an IP packet is dropped, then the entire IP packet must be resend and fragmented again.

 Fragmentation with GRE and IPsec tunnel

The biggest issue with IP fragmentation is related to GRE tunnel. Let’s take a look on the following example. Router A gets 1476B packet then adds GRE header into and sends to tunnel destination. Assume there is a router in the MPLS cloud with link MTU 1400B. This router will fragment GRE packet (GRE IP header, inner origanl IP and TCP headers will be only in the first fragment), in this case GRE tunnel destination router must reassemble the fragmented packets.

To avoid IP fragmentation the best way is to increase the MTU on whole packet way (so on each router on the path), in case of MPLS provider is not the issue because more and more vendors already increased this value up to 1600B to support IPsec or GRE without any problems. In case provider does not support higher MTU or transmit network is Internet we have three options: decrease IP MTU on tunnel interface, adjust MSS value or use PMTUD.  Let’s move from fragmentation theory and take a look how to take advantage of ping to discover the fragmentation issue related to MTU on the packet way and how it can be avoided.

Example – pure network

Suppose that we have pure network enviroment, two CE routers one in branch A and second one in remote branch B, we would confirm that MTU on the path especially minimum MTU in the provider MPLS cloud is equal to 1500B.

To test the MTU on the path the best option is to send the packets each time incrementing overall size. Extended ping feature with sweep option is perfect in this case. In the below example we do send ICMP echo request eith overall size equal to 1490B, we set sweep max size to 1510B where weep interval so we are going to increment each packet by 1B. Important option in this example is setting of Don’t Fragment bit.
Protocol [ip]:
Target IP address:
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1490
Sweep max size [18024]: 1510
Sweep interval [1]:
Type escape sequence to abort.
Sending 105, [1490..1510]-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 54 percent (50/91), round-trip min/avg/max = 40/99/224 ms

We have sent out 10 ICMP echo request starting from 1490B and we have got 10 responses, but next 10 pacets has not been answered at all, it’s means that packets was not be able to reach a final destination due to MTU, in fact pacekts longer then 1500B even has not been routed and leave router. Tested router has MTU equal 1500B configured on the interfaces so in the debug you can show that packets longer then 1500B has been routed just by FIB not by RIB like others.
*Mar 1 00:16:42.179: IP: tableid=0, s= (local), d= (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.183: IP: s= (local), d= (FastEthernet0/0), len 1499, sending
*Mar 1 00:16:42.183: ICMP type=8, code=0
*Mar 1 00:16:42.219: IP: tableid=0, s= (FastEthernet0/0), d= (FastEthernet0/0), routed via RIB
*Mar 1 00:16:42.223: IP: s= (FastEthernet0/0), d= (FastEthernet0/0), len 1499, rcvd 3
*Mar 1 00:16:42.227: ICMP type=0, code=0
*Mar 1 00:16:42.231: IP: tableid=0, s= (local), d= (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.231: IP: s= (local), d= (FastEthernet0/0), len 1500, sending
*Mar 1 00:16:42.231: ICMP type=8, code=0
*Mar 1 00:16:42.283: IP: tableid=0, s= (FastEthernet0/0), d= (FastEthernet0/0), routed via RIB
*Mar 1 00:16:42.287: IP: s= (FastEthernet0/0), d= (FastEthernet0/0), len 1500, rcvd 3
*Mar 1 00:16:42.291: ICMP type=0, code=0
*Mar 1 00:16:42.299: IP: tableid=0, s= (local), d= (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.299: IP: s= (local), d= (FastEthernet0/0), len 1501, sending
*Mar 1 00:16:42.303: ICMP type=8, code=0
*Mar 1 00:16:44.295: IP: tableid=0, s= (local), d= (FastEthernet0/0), routed via FIB
*Mar 1 00:16.:44.299: IP: s= (local), d= (FastEthernet0/0), len 1502, sending

Router sends 20 packets (starting from 1490 up to 1510, later on starting process again this is why we see exclamation mark and dots and exclamation again). We have sent 10 packets to starting from 1490 + 10 it means that last one was 1500B long and the router has 1500B MTU configured and droped the packets because was not able to fragment it due to DF bit set. The propose of this example was just to show way of test.

Example 2 – GRE over IPsec

Fragmentation can be a issue in case of use GRE over IPsec where end point that terminates the IPsec tunnel has to add GRE Header and next encrypts it all together. GRs header adds 24B to the packet, IPsec with ESP 56B so we have 80B overhead. As we have mentioned the best option to use in this case is PMTUD but what if routers on the path blocks the ICMP messages then the best option is to use optimum MTU size under tunnel GRE interface. GRE source router then will responsible for IP fragmentation befrore adding GRE and IPsec headers. To calulate the the MTU for tunnel the best option is to use sweep ping as above.

Let’s assume that we have GRE/IPsec between R1 and R3. We have experience issues related to the slow response time of application and high CPU on the R3 router. We expect that IP fragmentation is a culprit. We would to figure out what minimal MTU is on the path to adjust tunnel MTU to avoid IP fragmentation.
We are not able to ping with DF bit set to simulate traffic with GRE/IPsec because router will not copy DF bit in to IPsec header ( GRE tunnel cleares DF bit unless we use tunnel path-mtu discovery under tunnel GRE), istead of this we have to ping pure IP so for example remote head end of IPsec tunnel and be sure that this traffic will not be encrypted.

Test – test of minimal MTU on the path

Protocol [ip]:
Target IP address:
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1300
Sweep max size [18024]: 1500
Sweep interval [1]:
Type escape sequence to abort.
Sending 1005, [1300..1500]-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 68 percent (101/147), round-trip min/avg/max = 4/19/60 ms

After 101 successful request so we get response for ICMP with 1300B lenght until 1400B so the minimal MTU on the path is 1400B. M means could not fragment. Then recomended is to lower IP MTU under GRE to minimal MTU on the path – 80B (24B for GRE and 56B for ESP tunnel IPsec).

To read more about IP Fragmentation, MTU, MSS and PMTUD issues with GRE and IPsec I recomend to read this very good and interesting Cisco Technology White Paper.

, , , , ,

As I have promised I would present the basic configuration process of GET VPN.

In the production enviroment GET VPN technology will be deployed over MPLS WAN. In case MPLS network, CE routers exchange routing with PE routers so pure IP communications is achived between LAN to LAN (branch to branch). Additionaly each CE is aware that to route the traffic to specific CE (to CE’s MPLS interface IP) it has to push the traffic towards MPLS cloud.

We can imagine that my example presents part of MPLS WAN with Group Members (GM) as R2, R3 and Key Server (KS) as R4 that is located somewhere in Company HQ DC. To simplify the lab enviroment all GM routers are placed in one subnet, GM example will be configured on R2 (R1 and R3 will be configured similar, just different keys used). The main propose of GET VPN is to establish secure, efficient on demand any to any connectivity across private WAN. In the following example we achived encryption for branch to branch traffic (assumed that 10.0.x.x/16 IP addressing is used for branches).

Below IP addressing and LAB diagram:

  • R1 (GM) –
  • R2 (GM) –
  • R3 (GM) –
  • R4 (KS) –

Here you can find basic configuration steps to properly setup GET VPN architecture:

Group Member configuration

1. Internet Key Exchange (IKE) Phase 1

The same like in pure IPsec VPN we have to define ISAKMP policy on each GM and KS, so specify the encryption and hash algorithm, authentication method, Diffie-Hellman group and lifetime. As always all IKE Phase 1 parameters must match both sides to successfully established Phase 1.

I’m going to use 3DES as encryption algorithm and pre-share keys as authentication method, remaining will be default.
R2(config)#crypto isakmp policy 100
R2(config-isakmp)# encr 3des
R2(config-isakmp)# authentication pre-share
R2#show crypto isakmp policy
Global IKE policy
Protection suite of priority 100
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

It is possible to use the same pre-share key in whole GET VPN enviroment then each GM and KS needs just one kind of default pre-share key definition that looks like this one:
crypto isakmp key KEY address
Of course it is less secure solution then different key for each GM, but the best way of course is PKI architecture. For the LAB propose I use the different KEY for each GM. On R2 we have to defined KEY with peer address as KS so it will IP address.
R2(config)#crypto isakmp key 0 R2-KEY address
The same key has to be configured on the KS with R2 as GM peer IP address

2. Group Domain of Interpretation (GDOI) definition

After ISAKMP policy configuration we have to define GDOI on GM. Just two parameters are needed to properly define GDOI group on GM:

  • GDOI group identity number
  • KS IP address for that specific GDOI

R2(config)#crypto gdoi group GDOI-GROUP
R2(config-gdoi-group)#identity number 777
R2(config-gdoi-group)#server address ipv4

The GDOI-GROUP has been defined with identity number 777 that uniquely assign GMs to specific GDOI group on the KS and allows push the proper IPsec policy to them. Additionaly KS IP address has been configured, then GMs are aware to which KS they have to register.

3. GDOI crypto map configuration on GM
GDOI crypto map needs to be defined and GDOI-GROUP configured in point 2 is connected here.

R2(config)#crypto map GETVPN-MAP 100 gdoi
% NOTE: This new crypto map will remain disabled until a valid
group has been configured.
R2(config-crypto-map)#set group GDOI-GROUP

4. Apply GDOI crypto map to interface
The last step for GM is similar to the standard IPsec configuration, apply the crypto map to the external interface.
R2(config)#int fa0/0
R2(config-if)#crypto map GETVPN-MAP

As we see configuration of GET VPN and all IPsec parameters for GM is minimalized and thanks to this we have simply, fast and straight GET VPN deployment for CE routers. All IPsec policy is configured centrally on Key Server. Let’s take a look on the configuration of management router – Key Server.

Key Server configuration

1. Internet Key Exchange (IKE) Phase 1

As you are aware all IKE Phase 1 parameters must match both sides to successfully established Phase 1, so like on GM we have to define the same IKE policy here on KS:
R4(config)#crypto isakmp policy 100
R5(config-isakmp)# encr 3des
R4(config-isakmp)# authentication pre-share

As we have used the pre-share key authentication on GMs here we have to defined keys for each GM.
R4(config)#crypto isakmp key R1-KEY address
R4(config)#crypto isakmp key R2-KEY address
R4(config)#crypto isakmp key R3-KEY address

2. IPsec Phase 2 parameters – IPsec SA (transform-set and ipsec profile)
IPsec transofrm set defines the true IPsec encryption and authentication algorithms. 3DES and SHA with ESP have been used here. This IPsec policy will be part of GET VPN policy for specific GDOI group.
R4(config)#crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
IPsec transform set is defined under ipsec profile named GETVPN-PROFILE.
R4(config)#crypto ipsec profile GETVPN-PROFILE
R4(ipsec-profile)# set transform-set TRANSFORM-SET

3. Group Domain of Interpretation (GDOI) definition

RSA keys generation
First of all we have to generate the RSA keys. RSA key is generated only on the KS and is used to authenticate and sign rekey messages. The public key is sent to GMs at the registration. KS signs the rekeys with the private key and GMs verify the rekey messages using the public key. Additonaly public key of first KS has to be used by other KSs in case we would use redundant solution and ensure fault recovery architecture with more then one KS, this option is called as cooperative (COOP) KS. In case RSA keys need to be generated in exportable form and then imported to the redundant KSs.
R4(config)#crypto key generate rsa general-keys label GETVPN-R4-KS modulus 1024 exportable
The name for the keys will be: GETVPN-R4-KS
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]

GDOI group identity – config-gdoi-group mode
Once we have generated KS’s RSA keys we are able to start true GDOI group configuration, all configuration will be done under config-gdoi-group mode. First we have to confiugre the same identity number that we have deifned on GM, it’s 777:
R4(config)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#identity number 777

Local Key Server identification – gdoi-local-server mode
To designate a device as GDOI KS and enter GDOI local server configuration mode we have to enter server local command, then we will be able to configure all GDOI parameters that are related to the IPsec and rekey policy:
R4(config-gdoi-group)#server local

GDOI Rekey configuration
First step in GDOI policy is rekey parameters configuration, rekey authentication key pair (PKI or localy stored) and Key Server source address for rekey messages are required values to configure, additionaly we can define rekey retransmit timers.
R4(gdoi-local-server)#rekey authentication mypubkey rsa GETVPN-R4-KS
R4(gdoi-local-server)#address ipv4
R4(gdoi-local-server)#rekey retransmit 10 number 3 IP has been defined as source IP for rekey messages, localy generated RSA keys in point 3 will be used to authenticate rekey messages, additionaly rekey mechanism will be send with three retransmits at 10 second intervals.

IPsec policy configuration for the GDOI group
The IPsec policy defined under GDOI group at KS will be downloaded to all GMs. This global policy will exactly provides the IPsec parameters for phase 2. Policy defines IPsec encryption, authentication algorithms and define the crypto ACL that says interesting traffic for encryption, so it’s exactly what have been missed on GMs. So all what have been configured on each peer in case of pure IPsec site to site VPN now is confiugred only on the KS. We are able to manage and provision configuration from just one point of network to all GMs.

To configure the IPsec policy we have to first define the crypto ACL, we have to exclude the GDOI protocol and OSPF from the interesting traffic for IPsec encryption:

R4(config)#ip access-list extended CRYPTO-ACL
R4(config-ext-nacl)#deny udp any eq 848 any eq 848
R4(config-ext-nacl)#deny tcp any host
R4(config-ext-nacl)#deny tcp any host
R4(config-ext-nacl)#permit ip

Having ACL in place we can define the IPsec policy for GDOI group, we bind ipsec profile GETVPN-PROFILE that defines the transofrm set and crypto acl together under IPsec Security Association:

R4(config-ext-nacl)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#server local
R4(gdoi-local-server)# sa ipsec 1
R4(gdoi-sa-ipsec)#profile GETVPN-PROFILE
R4(gdoi-sa-ipsec)#match address ipv4 CRYPTO-ACL

That’s all GET VPN configured, up and running. Let’s see completed R4 configuration that is related to the GET VPN:
ip domain name
crypto isakmp policy 100
encr 3des
authentication pre-share
crypto isakmp key R1-KEY address
crypto isakmp key R2-KEY address
crypto isakmp key R3-KEY address
crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
crypto ipsec profile GETVPN-PROFILE
set transform-set TRANSFORM-SET
crypto gdoi group GDOI-GROUP
identity number 777
server local
rekey retransmit 10 number 3
rekey authentication mypubkey rsa GETVPN-R4-KS
rekey transport unicast
sa ipsec 1
match address ipv4 CRYPTO-ACL
replay counter window-size 64
address ipv4
ip access-list extended CRYPTO-ACL
deny udp any eq 848 any eq 848
deny tcp any host
deny tcp any host
permit ip

To see the configuration of the GDOI group:
R4#show crypto gdoi group GDOI-GROUP
Group Name : GDOI-GROUP (Unicast)
Group Identity : 777
Group Members : 2
IPSec SA Direction : Both
Active Group Server : Local
Group Rekey Lifetime : 86400 secs
Group Rekey
Remaining Lifetime : 84481 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 3
Group Retransmit
Remaining Lifetime : 0 secs
IPSec SA Number : 1
IPSec SA Rekey Lifetime: 3600 secs
Replay method : Count Based
Replay Window Size : 64
SA Rekey
Remaining Lifetime : 1682 secs
ACL Configured : access-list CRYPTO-ACL
Group Server list : Local

To see reigsitered GMs:
R4#show crypto gdoi ks members
Group Member Information :
Number of rekeys sent for group GDOI-GROUP : 1
Group Member ID :
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID :
Rekeys sent : 1
Rekeys retries : 3
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 1 2 3 4
Rcvd seq num : 0 0 0 0
Group Member ID :
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID :
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0

I hope this post will be helpfull to understand the base configuration steps for the GET VPN with pre-share keys.

, ,

Group Encrypted Transport (GET) VPN is called as next-generation tunnel-less VPN technology but is not replacement for old good known DMVPN. GET and DMVPN are complementary technologies and can be deployed together. 

Due to slow come up of the DMVPN spoke-to-spoke tunnels where IPSec tunnels are built dynamically based on the NHRP and multipoint GRE tunnels, tunnel negotiation time have direct impact for delay sensitive data like voice and video. In this case GET VPN is a good replacement solution where voice and video needs to be transmited between branches and faster static IPSec keys configuration and policy is in place before data go thru.

The distibuted nature of today’s network applications like voice, video and multicast traffic, constant growth of network threats and risks, local, federal and industry regulations, highly confidential traffic in financial enviroment are a key factors for efficient and secure WAN branch to branch interconnectivity.

WAN architecture demands has changed over years from the point-to-point and point-to-multipoint to full mesh connectivity. In today WAN network infrastructure where MPLS technology provides full mesh network connectivity between all branches most companies are still using centralized point-to-multipoint model with not efficient and slow dynamic tunnel negotiation process.

GET VPN is recomended solution when time sensitive data has to be encrypted in addition to multicast appliction and dynamic routing is needed over MPLS WAN architecture with full mesh connectivity.

Following are key fetures of GET VPN that have advantage over traditional IPSec VPN:

  • WAN transport full mesh encryption services on demand
  • Tunnel-Less Any-to-Any IPSec VPNs
  • Native routing
  • IP header preservation
  • Centralized key and policy management
  • Advanced QoS
  • Multicast connectivity
  • Reliability and redundancy of architecture

The key components of GET VPN are GDOI protocol, Key Server and Group Member.

Group Domain of Interpretation (GDOI) (RFC 3547)

  • Uses UDP 848
  • Cryptographic protocol for group policy/key management and distribution
  • Works based on ISAKMP
  • Establishes security associations between authorized group member routers
  • Uses two different encryption keys: Key Encryption Key (KEK) – key used to secure the control plane, Traffic Encryption Key (TEK) – key used to encrypt data traffic

Key Server (KS)

  • Authenticates Group Member (GM)
  • Distributes IPSec keys and policies to all registered and authenticated GMs
  • Perform rekey process

Group Member (GM)

  • Registers with KS to download IPSec VPN policy
  • Encrypts/decrypts traffic between among GMs in the same Group

GET VPN process can be divided on the following 5 steps.

  • Registration of GMs in the KS
  • Authentication and authorization of GMs by the KS
  • IPSec SA policy propagation from KS to GMs
  • GM encrypt/decrypt traffic based on group policy
  • Rekey process – IPSec SA keys replacement propagation 

In next post I’m going to provide you more process details and configuration example with GET VPN.

, ,