Securing Generic Routing Encapsulation With Internet Protocol Security (IPSec) For Institutional Wide Area Networks

International Journal of Advance Foundation and Research in Computer (IJAFRC)
Volume 2, Issue 11, November - 2015. ISSN 2348 4853, Impact Factor 1.317
Securing Generic Routing Encapsulation With Internet

Protocol Security (IPSec) For Institutional Wide Area
Networks
Seth Alornyo1, Michael Asante2
I.C.T Directorate, Koforidua Polytechnic1
Dept. Of Computer Science,KNUST, Kumasi-Ghana2
bigseth1099@yahoo.com1, mickasst@yahoo.com2
ABSTRACT
The Internet is a worldwide, publicly accessible IP network. Due to its vast global proliferation, it
has become a viable method of interconnecting remote sites. However, the fact that it is a public
infrastructure has deterred most enterprises from adopting it as a viable remote access method
for branch and SOHO (Small Office Home Office) sites. The paper discusses Generic Routing
Encapsulation (GRE) over Internet Protocol security (IPSec) Virtual Private Network (VPN) as a
concept that describes how to create a private network over a public network infrastructure
while maintaining confidentiality and security. A simulation of two network nodes over an ISP
network was used to allow packet flow from one network node through the Internet Service
Provider (ISP) to a destination network. This operation allowed packets sent from a source host
through the ISPs network to a destination network to be critically examined. Packet loss, packet
length, Input/output (I/O) graph, service response time and flow graph are some parameters
used to examine packet flow from a source host to a destination host over the ISP network. Open
source Network Protocol Analyzer was used to capture traffic traversing over the Service
Provider network for analysis and interpretation. Analyzed data revealed that all Transmission
Control Protocol (TCP) packet session were encapsulated with Encapsulated Security Payload
(ESP)Protocol. The encapsulation makes it impossible for the service provider to detect multicast
traffic over the service providers network and also crackers inability to decrypt the encapsulated
data over the internet.
Keywords: GRE, ISP, TCP PACKETS, ESP, VPN.IPSEC
I.
INTRODUCTION
GRE tunnels are stateless. Each tunnel endpoint keeps no information about the state or availability of
the remote tunnel endpoint. This feature helps Internet Service Providers (ISPs) provide IP tunnels to
customers who are not concerned about the internal tunneling architecture at the ISP end. Customers
then have the flexibility to configure or reconfigure their Internet Protocol (IP ) architecture but still
maintain connectivity. It creates a virtual point-to-point link to routers at remote points over an IP internetwork. Generic Routing encapsulation (GRE) over Internet Protocol Security- Virtual Private Network
(IPSEC-VPN) and IP-based physical security are best practice to overcome the mentioned problems. GRE
1 | 2015, IJAFRC All Rights Reserved
www.ijafrc.org

over IPSEC-VPN is a scalable technology, so it is a good solution for wide area network communications.
It also reduces the routing lookups in which case communication between different nodes becomes
faster. Virtual private network technology is used in order to provide simple management, low cost and
more flexibility for establishing Wide Area Networks.
GRE is a tunneling protocol defined in [1] and [2]. It was originally developed by Cisco Systems for
creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork, [3].
GRE supports multiprotocol tunneling. It can encapsulate multiple protocol packet types inside an IP
tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the
multiprotocol functionality. IP tunneling using GRE enables network expansion by connecting
multiprotocol sub-networks across a single-protocol backbone environment. GRE also supports IP
multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of
routing information in the virtual network [3].
II.
SECURING GENERIC ROUTING ENCAPSULATION (GRE)
The main function of GRE is to provide powerful yet simple tunneling. GRE supports any Open System
Interconnection (OSI) Layer 3 protocol as payload, for which it provides virtual point-to-point
connectivity. GRE also allows the use of routing protocols across the tunnel,[4].
The main limitation of GRE is that it lacks any security functionality as it only provides basic plaintext
authentication using the tunnel key, which is not secure, and tunnel source and destination addresses.
However a secure VPN requires characteristics such as;
Cryptographically strong confidentiality (encryption)
Data source authentication that is not vulnerable to man-in-the-middle attacks
Data integrity assurance that is not vulnerable to man-in-the-middle attacks and spoofing.
IPSec will provide the tunneling characteristics that GRE lacks:
Confidentiality through encryption using symmetric algorithms (for example, 3DES or AES)
Data source authentication using keyed-hash message authentication code (HMAC)(for example,
message-digest algorithm(MD5) or Secure Hash Algorithm(SHA-1)
Data integrity verification using HMACs
IPSec, however, was primarily intended to provide the above services to IP traffic only. Development of
Cisco IOS software is focused on removing the limitations, but multiprotocol support will always require
an additional tunneling protocol. Using crypto maps does not provide a virtual interface that you can
configure an address on, and a routing protocol can be run to dynamically exchange routing
information,[4] .
www.ijafrc.org

II. INTERNET PROTOCOL SECURITY (IPSEC)
III.
Internet Protocol Security (IPSec) is an Internet Engineering Task force (IETF) standard[5],[6], explained
how a VPN can be configured using the IP addressing protocol. IPSec is not bound to any specific
encryption, authentication, security algorithms, or keying technology. IPSec is a framework of open
standards that spells out the rules for secure communications. IPSec relies on existing algorithms to
implement the encryption, authentication, and key exchange.
IPSec works at the Network Layer, protecting and authenticating IP packets between participating IPSec
devices (peers). As a result, IPSec can protect virtually all application traffic because the protection can
be implemented from Layer 4 through Layer 7. All implementations of IPSec have a plaintext Layer 3
header, so there are no issues with routing. IPSec functions over all Layer 2 protocols, such as Ethernet,
ATM, Frame Relay, Synchronous Data Link Control (SDLC), and High-Level Data Link Control (HDLC).
The IPSec framework consists of five building blocks.
The first represents the IPSec protocol. Choices include ESP or AH.
The second represents the type of confidentiality implemented using an encryption algorithm
such as Data Encryption Standard (DES), Tripple Data Encryption Standard (3DES), Advance
Encryption Standard (AES), or Software-Optimized Encryption Algorithm (SEAL). The choice
depends on the level of security required.
The third represents integrity that can be implemented using either MD5 or SHA [7].
The fourth represents how the shared secret key is established. The two methods are pre-shared or
digitally signed using Rivest-Shamir-Adleman(RSA).
The last represents the Diffie-Hellman (DH) algorithm group. There are four separate DH key
exchange algorithms to choose from including DH Group 1 (DH1), DH Group 2 (DH2), DH Group 5
(DH5), and DH Group 7 (DH7). The type of group selected depends on the specific needs.
IPSec provides the framework, and the administrator chooses the algorithms that are used to implement
the security services within that framework. By not binding IPSec to specific algorithms, it allows newer
and better algorithms to be implemented without patching the existing IPSec standards [8].
IV. RIVEST-SHAMIR-ADLEMAN (RSA)
Signatures - The exchange of digital certificates authenticates the peers. The local device derives a hash
and encrypts it with its private key. The encrypted hash is attached to the message and is forwarded to
the remote end and acts like a signature. At the remote end, the encrypted hash is decrypted using the
public key of the local end. If the decrypted hash matches the recomputed hash, the signature is genuine.
www.ijafrc.org

Each peer must authenticate its opposite peer before the tunnel is considered secure. Figure 3 depicts a
pictorial view of RSA signature exchange between a local host and a remote host [9].
V. IPSEC SECURE KEY EXCHANGE
Encryption algorithms such as Data encryption Standard (DES) , 3DES, and Advanced Encryption
Standard (AES) as well as the Message-Digest Algorithm(MD5) and Secure Hash Algorithm (SHA-1)
hashing algorithms require a symmetric, shared secret key to perform encryption and decryption. The
shared secret keys between the routers are shared through Internet Key Exchange (IKE) protocol or
Internet Security Association (SA) and Key Management Protocol (ISAKMP).Email, courier. or overnight
express can be used to send the shared secret keys to the administrators of the devices. But the easiest
key exchange method is a public key exchange method between the encrypting and decrypting devices.
The Diffie-Hellman (DH) key agreement is a public key exchange method that provides a way for two
peers to establish a shared secret key that only they know, even though they are communicating over an
insecure channel [5].
Variations of the DH key exchange algorithm are known as DH groups. There are four DH groups: 1, 2, 5,
and 7.
DH groups 1, 2, and 5 support exponentiation over a prime modulus with a key size of 768 bits,
1024 bits, and 1536 bits, respectively.
Cisco 3000 clients support DH groups 1, 2, and 5. DES and 3DES encryption support DH groups 1
and 2.
AES encryption supports DH groups 2 and 5.
The CerticommovianVPN client supports group 7.
Group 7 supports Elliptical Curve Cryptography (ECC), which reduces the time needed to generate
keys[10].
VI. IPSEC SECURITY PROTOCOLS
IPSec is a framework of open standards. IPSec spells out the messaging to secure the communications but
relies on existing algorithms. The two main IPSec framework protocols are AH and ESP. The IPSec
protocol is the first building block of the framework. The choice of AH or ESP establishes which other
building blocks are available:
Authentication Header (AH) - AH, which is IP protocol 51, is the appropriate protocol to use when
confidentiality is not required or permitted. It ensures that the origin of the data is either R1 or R2 and
verifies that the data has not been modified during transit. AH does not provide data confidentiality
(encryption) of packets. All text is transported unencrypted. If the AH protocol is used alone, it provides
weak protection [11].
www.ijafrc.org

Encapsulating Security Payload (ESP) - ESP, which is IP protocol 50, can provide confidentiality and
authentication. It provides confidentiality by performing encryption on the IP packet. IP packet
encryption conceals the data payload and the identities of the ultimate source and destination. ESP
provides authentication for the inner IP packet and ESP header. Authentication provides data origin
authentication and data integrity. Although both encryption and authentication are optional in ESP, at a
minimum, one of them must be selected [11]. Figure 1 illustrates the recommended security protocol
process. Figure 4 shows how IPSec protocol header is encapsulated in an IP header for communication
between two peers. The encryption header (IP HDR) and authentication protocol all encapsulates the
packet (data) before been transmitted over the internet to the remote router. This ensures a high level of
security payload for a packet to be transmitted over the internet.
Figure 1: ESP Header [12]

VII. INTERNET KEY EXCHANGE (IKE)
IKE is defined in It is a hybrid protocol, combining the Internet Security Association (SA) and Key
Management Protocol (ISAKMP) and the Oakley and Secure Key exchange Mechanism (SKEME) key
exchange methods. ISAKMP defines the message format, the mechanics of a key-exchange protocol, and
the negotiation process to build an SA for IPSEC. ISAKMP does not define how keys are managed or
shared between the two IPsec peers. Oakley and SKEME have five defined key groups. Of these groups,
Cisco routers support Group 1 (768-bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key) [12].
To implement a VPN solution with encryption, it is necessary to periodically change the encryption keys.
Failure to change these keys makes the network susceptible to brute-force attacks. IPsec solves the
problem of susceptibility with the Internet Key Exchange (IKE) protocol, which uses two other protocols
to authenticate a peer and generate keys. The IKE protocol uses the DH key exchange to generate
symmetrical keys to be used by two IPsec peers. IKE also manages the negotiation of other security
www.ijafrc.org

parameters, such as data to be protected, strength of the keys, hash methods used, and whether packets
are protected from replay. IKE uses UDP port 500 [13].
IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec
exchange, and consists of all the parameters that are required to establish successful communication,
[14]
IPsec uses the IKE protocol to provide these functions:
Negotiation of SA characteristics
Automatic key generation
Automatic key refresh
Manageable manual configuration
A security association (SA) requires the following:
Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP is a

protocol framework that defines the mechanics of implementing a key exchange protocol and
negotiating a security policy. ISAKMP can be implemented over any transport protoco [15] .
SKEME: A key exchange protocol that defines how to derive authenticated keying material with
rapid key refreshment.
OAKLEY: A key exchange protocol that defines how to acquire authenticated keying material. The
basic mechanism for OAKLEY is the DH key exchange algorithm[17]. IKE automatically negotiates
IPSec SAs and enables IPSec secure communications without costly manual pre-configuration. An
alternative to using IKE is to manually configure all parameters required to establish a secure
IPSec connection. This process is impractical because it does not scale, [16].
IKE includes these features:
Eliminates the need to manually specify all of the IPSEC security parameters at both peers.
Allows specification for a lifetime for the IPSEC Security Association (SA)
Allows encryption keys to change during IPSEC sessions
Allows IPSEC to provide anti-replay services
Permits certification authority (CA) support for a manageable, scalable IPSEC implementation
Allows dynamic authentication of peers [17].
VIII. INTERNET KEY EXCHANGE (IKE) PROCESS

To establish a secure communication channel between two peers, the IKE protocol executes two phases:
Phase 1 - Two IPSec peers perform the initial negotiation of SAs. The basic purpose of Phase 1 is
to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the
peers. It can be implemented in main mode (longer, initial contact) or aggressive mode (after
initial contact).
Phase 2 - SAs are negotiated by the IKE process ISAKMP on behalf of IPSEC. The second exchange
creates and exchanges the DH public keys between the two endpoints. DH allows two parties that
www.ijafrc.org

have no prior knowledge of each other to establish a shared secret key over an insecure
communications channel. The two peers run the DH key exchange protocol to acquire the keying
material that is needed by the various encryption and hashing algorithms upon which IKE and
IPSec will ultimately agree.
The purpose of IKE Phase 2 is to negotiate the IPSec security parameters that will be used to secure the
IPSec tunnel. IKE Phase 2 is called quick mode and can only occur after IKE has established the secure
tunnel in Phase 1. SAs are negotiated by the IKE process ISAKMP on behalf of IPSec, which needs
encryption keys for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that
IPSec uses are unidirectional; therefore, a separate key exchange is required for each data flow [14].
IX. METHODOLOGY
The method adopted in this paper is the structural design and the simulation of GRE tunnel network.
Graphical Network Simulator (GNS3) software was used to simulate the network with Cisco routers
running original Internetwork Operating System (IOS). GNS3 is software used to simulate complex
advances network. Network device configuration and penetration testing can be established when using
GNS3. Routers used in the simulation are Cisco routers. Comparative analysis and penetration testing
was done to check the security level of a GRE tunnels. Network Protocol Analyzer (wireshark) was used
to capture traffic traversing over the Service Providers network for further analysis and interpretation.
The following is the description of methods used to simulate the tunnel.
X.
SIMULATED VIRTUAL LAB
In the simulated virtual lab, a site-to-site GRE tunnel VPN was configured. Once configured, the VPN
traffic between Router 1 on interfaces Router 1 and Router 2will be captured using wireshark for further
processing and analysis. Each of the simulated networks connects to an Internet Service Provider
(ISP).The Internet Service Provider only provides internet subscription to the client (institution).The
simulated network will provide institutional connectivity to remote sites over the internet. A study into
Service Providers network architectural design outline certain configuration parameters which allows
internet subscription from client and other IP services hosted by the Service Provider. In the process
architectural designs of Service Providers to were simulated to allow connectivity to client. Figure 7
illustrates the topological simulated design used to simulate the network architecture. The ISP has two
routers (ISP1 and ISP 2).ISP 1 connects router 1 and ISP 2 connects router 2. Router 1 and 2 are
considered as the edge routers and a client to the ISP. The ISP has a serial connection from ISP 1 to
ISP2.ISP 1 connects its edge router through a fast ethernet 0/0 interface and ISP2 connects its edge
router through a fast ethernet 0/0 interface. The ISP provides only internet access to router 1 and 2(edge
devices). A virtual cloud adaptor from figure 2 was used to virtualized the physical interface of a laptop
www.ijafrc.org

network adaptor to a Loopback adaptor interface. This virtualization enabled a laptop adaptor to be part
of the simulated network.
Figure 2: Simulated GRE over IPSec VPN tunnel Laboratory (authors)
XI. TYPE-STYLE AND FONTS

Configuration of Network Interface Addresses
A loopback and a tunnel interface was configured on router 1 and router 2 fast ethernet and the serial
interfaces. Fast ethernet 0/0 on router 1 was configured with the IP address 200.1.1.1 and a subnet
mask 255.255.255.0.The IP address configured on fast ethernet 0/0 is the out bound interface connected
to the service provider (ISP1) for internet access. Loopback interface 0 was configured with the IP
address 1.1.1.1 and a subnet mask 255.255.255.0.The loopback interface represent all internal hosts
connected to router 1.
Router 2 was also configured with the same parameters. The loopback interface was assigned the IP
2.2.2.2 and a subnet mask 255.255.255.0.Fastethernet 0/0 connects to Internet Service Provider (ISP2)
for internet access. Fastethernet 0/0 was assigned the IP 200.1.2.2 and a subnet mask 255.255.255.0.A
no shutdown command was issued on each of the configured interface to activate the interfaces.
A tunnel interface (tunnel 0) on router 1 and router 2 which will be used to transport GRE packets from
router 1 and router 2 was configured with the IP 12.12.12.1 and 12.12.12.2 respectively. Tunnel 0 was
virtualized with the physical interface fast ethernet 0/0 to transport packets flow through the physical
interface connected to the Internet Service Provider (ISP). The command tunnel source 20.1.1.1 and a
tunnel destination 200.1.2.2 was issued on both routers to connect the tunnel (tunnel 0) interface to the
physical interface to transport packets to the ISP. Configured tunnel 0 on router 1 and router 2 will be
the transport medium to forward all VPN traffic through the ISPs network.
ISP (Internet Service Provider) network as shown in figure 14was simulated with two routers, ISP1 and
ISP2. ISP 1 has two interfaces, interface fastethernet 0/0 and interface serial 1/0.Interface fastethernet
www.ijafrc.org

0/0 connects router 1 and interface serial 1/0 connects ISP 2. Fastethernet 0/0 was configured on ISP 1
router with the IP address 200.1.1.2 and a subnet mask 255.255.255.0,interface serial 0/0 also
configured with the IP address 200.11.22.1 with subnet mask 255.255.255.25.Each configured interfaces
were issued with the command no shut down to activate the interfaces.
ISP2 router has two interfaces,interface fastethernet 0/0 and interface serial 1/0.Interface fast ethernet
0/0 connects router 1 and serial 1/0 connects ISP2 serial interface 1/0. Interface fast ethernet 0/0 was
configured with the IP address 200.1.1.1 with a subnet mask 255.255.255.0 and interface serial 1/0 with
an IP address 200.11.22.2 subnet 255.255.252.A no shut down command was issued on each interfaces
to activate the interface.
Configuring Routing Protocol On Client Routers.
In order to maintain connectivity between remote networks, EIGRP was configured to route packets
between all networks in the diagram. All connected subnets were added into the EIGRP autonomous
system on every router. The command:
Router eigrp 1
Network 10.0.0.0
Network 12.0.0.0
Network 192.168.0.0
The command router eigrp 1 enables and activates Enhanced Interior Gateway Routing Protocol (eigrp)
under one (1)Autonomous System on router 1, the command network 10.0.0.0,12.0.0.0.192.168.0.0
advertises the network which is directly connected torouter 1, to the ISP1 network.
The command router eigrp1
Network 12.0.0.0
Network 2.0.0.0
Network 192.168.0.0
The command router eigrp 1 enables and activates Enhances Interior Gateway Routing Protocol under
one (1) Autonomous System on router 2, the command network 12.0.0.0, 2.0.0.0 , 192.168.0.0 advertises
the network which is directly connected to router 2, to the ISP2 network. Configuring autonomous
system enables EIGRP to be under one administrative control.
Configuring Routing Protocol On ISP Routers.
The simulated network has two routers which establish connectivity to both clients (router 1 and router
2). Routing Information Protocol version 2 (RIP,v2) was configured on the ISPs routers. This enables the
ISP router receives network advertisement from router 1 and router 2 network.ISP1 router has two main
www.ijafrc.org

interfaces, interface fast ethernet 0/0 and interface serial 0/1.Interface fast ethernet 0/0 is directly
connected to router 1and interface serial 0/1 connected to ISP2 network. ISP 1 router was configured
with the command;
Router rip version 2
Network 200.1.1.0
Network 200.11.22.0
ISP 2 router has two main interfaces, interface fastethernet0/0 and serial 0/1.Interface fast ethernet 0/0
is connects router 2 and interface serial 0/1 connects to ISP 2 network.
ISP 2 router was configured with the command;
Router rip version 2
Network 200.1.2.0
Network 200.11.22.0
Networks advertised on ISPs router are networks which are connected to interface fastethernet 0/0to
router 1 and interface serial 0/0 to ISP2 interface. Networks advertised on ISP2 router are networks
which connected to interface fast ethernet 0/0 to router 2 and interface serial 0/0 to ISP1.
A ping command was issued from router 1 to the various configured interface to verify that connectivity
across local subnets using the ping command was reachable. All ping commands sent were all successful.
Step one (1) to step three (3) are the processes used to simulate the GRE tunnel from router 1 through
the ISPs network to router 2.
XII. SECURING GENERIC ROUTING ENCAPSULATION (GRE) TUNNEL WITH IPSEC
Configuring IKE Policies
There are two central configuration elements to the implementation of an IPSec:

1. Implement Internet Key Exchange (IKE) parameters
2. Implement IPSec parameters
The exchange method employed by IKE is first used to pass and validate IKE policies between peers.
Then, the peers exchange and match IPSec policies for the authentication and encryption of data traffic.
The IKE policy controls the authentication, encryption algorithm, and key exchange method used for IKE
proposals that are sent and received by the IPSec endpoints. The IPSec policy is used to encrypt data
traffic sent through the VPN tunnel. Internet Security Association Key Management Protocol (ISAKMP)
was used to enable IKE on the client router (router 1).
The exchange method employed by IKE is first used to pass and validate IKE policies between peers.
Then, the peers exchange and match IPSEC policies for the authentication and encryption of data traffic.
The IKE policy controls the authentication, encryption algorithm, and key exchange method that is used
www.ijafrc.org

by IKE proposals that are sent and received by the IPSEC endpoints. The IPSEC policy is used to encrypt
data traffic that is sent through the GRE tunnel.
To allow IKE Phase 1 negotiation, an Internet Security Association and Key Management Protocol
(ISAKMP) policy was created and a peer association involving that ISAKMP policy was also configured.
An ISAKMP policy defines the authentication and encryption algorithms and hash function used to send
control traffic between the two VPN endpoints. When an ISAKMP security association has been accepted
by the IKE peers, IKE Phase 1 has been completed. The command configured on router 1 must match the
command configured on router 2. Router 1 and router 2were configured with the commands:
R1(config)# crypto isakmp policy 5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# encryption aes 256
R1(config-isakmp)# hash sha
R1(config-isakmp)# group 5
R1(config-isakmp)# lifetime 3600
R2(config)# crypto isakmp policy 10

R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# encryption aes 256
R2(config-isakmp)# hash sha
R2(config-isakmp)# group 5
R2(config-isakmp)# lifetime 3600
The different priority numbers refer to how secure a policy is. The lower the policy number is, the more
secure a policy is. Routers will check to verify which security policies are compatible with their peer,
starting with the lowest numbered (most secure) policies.
Configuration of Router Pre-Share Keys
Since I chose pre-shared keys as our authentication method in the IKE policy, I configure a key on each
router corresponding to the other VPN endpoint. These keys must match up for authentication to be
successful and for the IKE peering to be completed. For simplicity Iused the key MYKEY. Router 1 and
router 3 were configured with the command:
R1(config)# crypto isakmp key MYKEY address 200.1.2.2
R2(config)# crypto isakmp key MYKEY address 200.1.1.1
Configuration of Router IKE Phase two (2)
Router 1 and router 2 was configured with the command:
R1(config)# crypto ipsec transform-set LABesp-aes 256 esp-sha-hmac ah-sha-hmac
R2(config)# crypto ipsec transform-set LABesp-aes 256 esp-sha-hmac ah-sha-hmac.
R1(config-crypto-map)# match address KNUST
www.ijafrc.org

IKE phase 2 is configured using the IPSec transform set. TheIPSec transform set is another crypto
configuration parameter that routers negotiate to form a security association. Routers will compare their
transform sets to the remote peer until they find a transform set that matches exactly.
Configuration of the Interesting Traffic
Now that most of the encryption settings are configured, extended access was defined lists to tell the
router which traffic to encrypt. Like other access lists used to define interesting traffic rather than
packet filtering, permit and deny do not have the usual meaning of a filtering access list. A packet which is
permitted by an access list used for defining IPSec traffic will get encrypted if the IPSec session is
configured correctly. A packet that is denied by one of these access lists will not be dropped; it will be
sent unencrypted. Also, like any other access list, there is an implicit denialat the end, which in this case
means the default action is not to encrypt traffic. If there is no IPsec security association correctly
configured, then no traffic will be encrypted, but traffic will be forwarded as unencrypted traffic. Router 1
and router 2 were configured with the following command:
R1(config)# ip access-list extended KNUST
R1(config)# permit ip 12.12.0.0 0.0.255.255 12.12.0.0 0.0.255.255
R1(config)# ip access-list extended KNUST
R1(config)# permit ip 12.12.0.0 0.0.255.255 12.12.0.0 0.0.255.255
In this configuration, the traffic l want to be encrypted is the GRE tunnel traffic which was configured
with the IP address 12.12.12.0/24.The access-list was configured with a name KNUST to only allow traffic
going through the GRE tunnel 0 encrypted with IPSec.
Configuration And Application of Crypto Map
Router 1 and router 2 were configured with the following commands:
R1(config)#crypto map VPN_MAP 15 ipsec-isakmp
R1(config-crypto-map)# set peer 200.1.2.2
R1(config-crypto-map)# set transform set LAB
R1(config-crypto-map)# lifetime 900
R2(config)#crypto map VPN_MAP 15 ipsec-isakmp
R2(config-crypto-map)# set peer 200.1.1.1
R2(config-crypto-map)# match address KNUST
R2(config-crypto-map)# set transform set LAB
R2(config-crypto-map)# lifetime 900
A crypto map is a mapping that associates traffic matching an access list (like the one I created earlier) to
a peer and various IKE and IPsec settings. Crypto maps can have multiple map statements, so you can
have traffic that matches a certain access list being encrypted and sent to one IPsec peer, and have other
traffic that matches a different access list being encrypted towards a different peer. After a crypto map is
created, it can be applied to one or more interfaces. The interface(s) that it is applied to should be the
www.ijafrc.org

one(s) facing the IPSec peer.The name of the configured crypto map is known as VPN_MAP. This name
will be applied to the interface to secure VPN traffic.
Applying Cryptographic Map To An Interface
The interface that need to be secured is the GRE tunnel interface. The cryptographic map was applied to
the tunnel (tunnel 0) interface to secure traffic from router 1through ISPs network to router 2. Router 1
and 2 were configured with the following commands:
R1(config)# interface tunnel 0
R1(config)#crypto map VPN_MAP
R2(config)# interface tunnel 0
R2(config)#crypto map VPN_MAP
XIII.
RESULT AND ANALYSIS
Verification Of Internet Protocol (IP) VPN Tunnel Interfaces

The command show ip interface brief was issued on router one (1) to verify IP address configuration
parameters and interface status, figure 8 depict the output of the command.
Figure 3 depicts the connectivity between router one (1) and the ISPs network. Fastethernet 0/0 with an
IP address 200.1.1.2 connects to the ISP two (ISP 1) network which shows that the interconnectivity
between the client router and the service provider is active (up) whiles the protocol supporting the
interface is also active (up).Interface tunnel 0 configured for Generic Routing Encapsulation (GRE) over
Internet Protocol Security Virtual Private Network (GRE/IPSec-VPN) is also active (up).Clients connected
to router one (1) can tunnel through (tunnel 0) the ISPs network to router two (2).Hence the tunnel
connectivity between router one (1) and router two (2) has being established through the tunnel
interfaces.
Figure 3: Simulated GRE tunnel interface verification

XIV. SECURED GRE OVER IPSEC TUNNEL OPERATIONS STATUS
www.ijafrc.org

A continuous Internet Service Control Messaging Protocol (ICMP), service command ping 12.12.12.2
was executed on a laptop with an IP address 19.168.1.2 attached to the Local Area Network connected to
router 1, through the ISP network over to the destination tunnel network on router 2.
A web server hosted on router 2 was also accessed by the laptop with an IP address 192.168.1.2
connected to the simulated network. All Hypertext Transmission Protocol (HTTP) traffic were sent over
the VPN tunnel (tunnel 0).A Network Protocol Analyzer software (wireshark) was used to capture
packets moving through the ISP network to router 2. Figure 4 displays the outcome of the output
command from router 1 through the ISP network to router 2.
Wireshark was used to capture traffic between the clients connected to router one (1) through the ISPs
network. The highlighted session in green depicts packet sent from a source tunnel network with an IP
address 200.1.2.2 to a destination network 200.1.1.1 has being secured by the Encapsulation Security
Protocol (ESP).The highlighted session in red is the interior routing protocol configured on the ISP
network to exchange hello packets among the router for a best path selection. Any conversation
between the two routers through the tunnel network traversing over the ISPs network cannot be seen or
intercepted by a third party.ESP protocol are the only packets being exchanged on the ISPs network.ESP
encapsulates all TCP packets before transporting the packets through the tunnel network (tunnel 0)
Figure 4: Captured GRE over IPSec-VPN Packets using Wireshark

Figure 5 illustrates the analysis of packet captured over the ISP network. Traffic sent over the VPN
tunnel includes web traffic (HTTP:80), IP traffic, User Datagram Protocol (UDP),Transmission Control
Protocol (TCP) and Ethernet broadcast address (ffffffffff).
www.ijafrc.org

Graph 1 has the color black which has an IP filter witha styleline, Graph 2 has the color red which has a
TCP session filter with a style Fbar,graph 3 has the color green which has an HTTP filter with a style
impulse, graph 4 has the color blue which has a User Datagram Protocol (UDP) filter with a style Fbar,
and graph 5 has the pink color which has a broadcast IP (ffffffff) with a style dot.
The output of figure 10 indicates that only IP and UDP traffic traversed over the VPN tunnel.TCP and
HTTP traffic were not captured within the tunnel.This analysis prove that all HTTP requests and TCP
sessions were all encapsulated by the IPSec protocol (ESP) within the IP(Internet Protocol) header,which
means efforts to capture any TCP or HTTP traffics will prove futile because TCP packets have being
encapsulated within the tunnel by Encapsulated Security Payload (ESP), hence TCP traffics cannot be
captured over the tunnel network.
Figure 5: Simulated IPSEC-VPN Input/output (I/O) graph

XV. CONCLUSION
The use of GRE over IPSec VPN technology can further be used to establish Network connectivity instead
of establishing Wide Area Connection through satellite medium or outsourced to service providers.
Internet Protocol Security (IPSec) VPN(Virtual Private Network) mainly supports unicast traffic but a
simulated study on this paper revealed that multicast traffic can operate securely over the Generic
Routing Encapsulation (GRE) tunnel network when secured with Internet Protocol Security (IPSec).HTTP
and any other TCP packets can securely be sent through a secured VPN tunnel without the Service
provider knowing the type of packets being sent across their network because the service provider only
see Encapsulated Security Payload (ESP) packets on their network but not the content of the ESP packets
traversing over their network.
www.ijafrc.org

XVI. FUTURE WORK

The future work will involve the detection of penetration attempts to private and public network
infrastructure and the prescription of solutions on how to prevent such attacks.
XVII. REFERENCES
[1]
Hanks S., Li, T., Farinaci,P. Traina, D Generic Routing Encapsulation over IPv4 networks,Cisco
Systems, October 1994,rfc1702
[2]
[3]
[4]
[5]
Hanks S., Li, Farinaci,P. Traina, D Generic Routing Encapsulation over IPv4 networks Juniper
Networks,March 2000.rfc2784
Farinacci, D., Traina, P., Hanks, S., & Li, T. (1994).Generic routing encapsulation (GRE).retrieved
from http://xml2rfc.tools.ietf.org/html/rfc1701.
Christian, P. Generic Routing Encapsulation over CLNS Networks.RFC-3147,July 2001.retrieved
from http://www.hjp.at/doc/rfc/rfc3147.html.
Kent, S., & Atkinson, R. (1998). Security architecture for the internet protocol retrieved from
http://www.hjp.at/doc/rfc/rfc2401.html.
[6]
Thayer, R., Doraswamy,Glenn, R IP Security Roadmap Network

November,1998 ,rfc2411
[7]
Madson, C., & Glenn, R. (1998) The use of HMAC-MD5-96 within ESP and AH,1998 retrieved
from http://tools.ietf.org/html/rfc2403.
Karn, P., Simpson, W. A., & Metzger, P.). The esp des-cbc transform 1995. retrieved from
http://tools.ietf.org/html/rfc1829.
[8]
Cisco System, Cisco

Annual Security Report, 2014,page
https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf.
[10]
Prafullchandra, H., &Schaad, J. (2000). Diffie-Hellman proof-of-possession algorithms).
[11]
Atkinson, R., & Kent, S. (1998).

http://xml2rfc.tools.ietf.org/html/rfc2402.
[12]
Atkinson, R., & Kent, S. (1998). IP encapsulating security payload (ESP),retrieved from
http://tools.ietf.org/html/rfc2406
[13]
Harkins, D., & Carrel, D. (1998). The internet key exchange (IKE). RFC 2409, november.ISO/IEC
17799, (2005) Information technology -- Security techniques -- Code of practice for information
security management.
[14]
Yang, W., Li, C. D., Chang, G. R., Yao, Y., &Shen, X. M. (2011). The Effect of P 2 P - Based Work
Propagation in an IPv6 Internet. Procedia Engineering, 15, 3637-3641.
[15]
Simpson, W. A. (1999). IKE/ISAKMP considered harmful. USENIX; login, 24(6).
[16]
Matthews, G. A., & Feinstein, B. S. (2007). The Intrusion Detection Exchange Protocol
(IDXP).retrieved from http://tools.ietf.org/html/rfc4767.
authentication
retrieved
Group,
[9]
IP
68,
Working
header,retrieved
from
from
www.ijafrc.org

[17]
Orman, H., The OAKLEY Key Determination Protocol Department of Computer Science.
university of Arizona,Novemeber,1998,(rfc2412).
www.ijafrc.org

Securing Generic Routing Encapsulation With Internet Protocol Security (IPSec) For Institutional Wide Area Networks

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Securing Generic Routing Encapsulation With Internet Protocol Security (IPSec) For Institutional Wide Area Networks

Încărcat de

Drepturi de autor:

Formate disponibile

International Journal of Advance Foundation and Research in Computer (IJAFRC)