Skip to main content

GRE VPN on Cisco IOS

Cisco GRE VPN

Tunneling Overview

Tunnels provide a way to transport protocols that the underlying network does not support. There are several reasons why this may be:
·       The network infrastructure doesn’t support the protocol being used
·       The network infrastructure cannot route the packets due to lack of routing information or addressing types (public addressing vs. private addressing)
·       The network infrastructure doesn’t support the traffic type (multicast or broadcast)

The most common use case for tunnels is to connect remote, geographically separated sites over an existing network, most notably routing over a public infrastructure (such as the Internet). When used in this manner, tunnels create VPN overlay networks between remote sites. Packets destined to remote private networks are encapsulated within a new IP header that is used to traverse the public internet.

GRE Tunnels

GRE tunnels provide an interface the device can use to forward data. The “data” in this sense is the passenger protocol itself, such as IPv6 or IPv4. These tunnels are comprised of three main components:
1.     Delivery Header (Transport Protocol)
2.     GRE Header (Carrier Protocol)
3.     Payload Packet (Passenger Protocol)

GRE can be used with many different combinations of passenger and transport protocols. However, IPv4 and IPv6 are the most common transport protocols for GRE. For example:
·       GRE can use IPv4 as the transport protocol to tunnel an IPv4 packet across the underlying network infrastructure.
·       GRE can use IPv4 as the transport protocol to tunnel an IPv6 packet across the underlying network infrastructure.
·       GRE can use IPv6 as the transport protocol to tunnel an IPv4 packet across the underlying network infrastructure.

·       GRE can use IPv6 as the transport protocol to tunnel an IPv6 packet across the underlying network infrastructure.


Why Use GRE Tunnels?

GRE’s support for multiple protocols and packet types makes it ideal for solving many of the problems faced when trying to form VPNs across the Internet. The most obvious issue is that private addressing used in the enterprise cannot be routed across the public Internet. GRE solves this by encapsulating the IP header with private addressing using an outer IP header that uses public addressing.


GRE can be used to solve both of these problems:
1.     GRE supports multicast traffic allowing hello messages generated by an IGP to be transported through the GRE tunnel across the underlying infrastructure as a unicast packet. IPsec can then be used to encrypt all traffic flowing through the GRE tunnel.

2.     GRE configuration creates a logical direct connection between two sites over the underlying infrastructure. This means the control plane of the IGP believes it is directly connected to the neighbour with which it is exchanging hellos and therefore can form the adjacency.


Task-1: Configure GRE VPN between R1 & R2 for making communication between both private sides.

Task-2: Implement GRE Over IPSEC Setup Between R1 and R2 for securing communication between both private side using following parameters:

ISAKMP Parameters:
Encryption: 3DES
Authentication Pre-Share
DH-Group: 2
Hash: MD5
    Key: Cisco123

IPSEC Parameters:
Encryption: AES
Hash: SHA

Initial Configuration:

R1:

interface FastEthernet0/0
 ip address 192.1.10.1 255.255.255.0
 duplex auto
 speed auto
end

interface Loopback0
 ip address 10.1.1.1 255.255.255.0
end

ip route 0.0.0.0 0.0.0.0 192.1.10.2


R2:

interface FastEthernet0/0
 ip address 192.1.20.3 255.255.255.0
 duplex auto
 speed auto
end

interface Loopback0
 ip address 10.2.2.2 255.255.255.0
end

ip route 0.0.0.0 0.0.0.0 192.1.20.2ISP:


ISP:

interface FastEthernet0/0
 ip address 192.1.10.2 255.255.255.0
 duplex auto
 speed auto
end

interface FastEthernet0/1
 ip address 192.1.20.2 255.255.255.0
 duplex auto
 speed auto
end


Task-1: Configuring GRE Tunnel between R1 & R2.

Step-1: Configuring Tunnel interface

Solution:

R1:

interface Tunnel1
 ip address 192.168.1.1 255.255.255.0
 tunnel source 192.1.10.1
 tunnel destination 192.1.20.3
end

R2:

interface Tunnel1
 ip address 192.168.1.2 255.255.255.0
 tunnel source 192.1.20.3
 tunnel destination 192.1.10.1
end

Note: Tunnel Source & Destination addresses should be reachable from both ends via some other link (Other than Tunnel interface) like: Wan Links.

Step-2: Configuring Routing between both R1 & R2, for advertising Private Networks and Tunnel Networks.

R1:

router eigrp 1
 network 10.0.0.0
 network 192.168.1.0
 no auto-summary

R2:

router eigrp 1
 network 10.0.0.0
 network 192.168.1.0
 no auto-summary

Verification:

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/127/144 ms
R2#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/35/52 ms

R1#show ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.1.10.2 to network 0.0.0.0

C    192.1.10.0/24 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
D       10.2.2.0 [90/297372416] via 192.168.1.2, 00:21:24, Tunnel1
C       10.1.1.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel1
S*   0.0.0.0/0 [1/0] via 192.1.10.2

R2#show ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.1.20.2 to network 0.0.0.0

C    192.1.20.0/24 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.2.2.0 is directly connected, Loopback0
D       10.1.1.0 [90/297372416] via 192.168.1.1, 00:21:18, Tunnel1
C    192.168.1.0/24 is directly connected, Tunnel1
S*   0.0.0.0/0 [1/0] via 192.1.20.2

R1#ping 10.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/112/116 ms

R2#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/41/48 ms


Task-2: Implement GRE Over IPSEC Setup Between R1 and R2 for securing communication between both private side using following parameters:

Solution:

R1:

Step-1: Configure Phase-1 ISAKMP Policy:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.20.3

Step-2: Configure Phase – 2 IPSEC Transform-Set

crypto ipsec transform-set TSET esp-3des esp-sha-hmac

Step-3: Configure IPSEC Profile

crypto ipsec profile IPSEC-PROF
 set transform-set TSET 

Step-4: Apply IPSEC Profile under Tunnel interface

interface Tunnel1
 tunnel protection ipsec profile IPSEC-PROF
end

R2:

Step-1: Configure Phase-1 ISAKMP Policy:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.10.1

Step-2: Configure Phase – 2 IPSEC Transform-Set

crypto ipsec transform-set TSET esp-3des esp-sha-hmac

Step-3: Configure IPSEC Profile

crypto ipsec profile IPSEC-PROF
 set transform-set TSET 

Step-4: Apply IPSEC Profile under Tunnel interface

interface Tunnel1
 tunnel protection ipsec profile IPSEC-PROF
end

Verification:

R1#show crypto isakmp sa 
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
192.1.20.3      192.1.10.1      QM_IDLE           1001    0 ACTIVE


R2#show crypto isakmp sa 
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
192.1.20.3      192.1.10.1      QM_IDLE           1001    0 ACTIVE


R1#show crypto ipsec sa 

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 192.1.10.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.1.10.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.1.20.3/255.255.255.255/47/0)
   current_peer 192.1.20.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 613, #pkts encrypt: 613, #pkts digest: 613
    #pkts decaps: 607, #pkts decrypt: 607, #pkts verify: 607
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 2, #recv errors 0

     local crypto endpt.: 192.1.10.1, remote crypto endpt.: 192.1.20.3
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xC14FAFC3(3243225027)

     inbound esp sas:
      spi: 0xA739CCF6(2805583094)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4567902/873)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xC14FAFC3(3243225027)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4567901/873)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE


R2#show crypto ipsec sa

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 192.1.20.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.1.20.3/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.1.10.1/255.255.255.255/47/0)
   current_peer 192.1.10.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 617, #pkts encrypt: 617, #pkts digest: 617
    #pkts decaps: 623, #pkts decrypt: 623, #pkts verify: 623
    #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.: 192.1.20.3, remote crypto endpt.: 192.1.10.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xA739CCF6(2805583094)

     inbound esp sas:
      spi: 0xC14FAFC3(3243225027)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4511307/867)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xA739CCF6(2805583094)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4511308/867)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE


R1#show interfaces tunnel 1
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 192.168.1.1/24
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.1.10.1, destination 192.1.20.3
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "IPSEC-PROF")
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     627 packets input, 53444 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     633 packets output, 53968 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

R2#show interfaces tunnel 1
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 192.168.1.2/24
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.1.20.3, destination 192.1.10.1
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "IPSEC-PROF")
  Last input 00:00:03, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     639 packets input, 54472 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     633 packets output, 53948 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/50/76 ms

R2#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/40 ms
R2#

R1#ping 10.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/33/60 ms


Thank You !!! 

Comments

Post a Comment

Popular posts from this blog

VRF Aware IPSEC Site-to-Site VPN

VRF [Virtual Routing & Forwarding] Virtual Private Networks (VPNs) provide a secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a  VPN routing/forwarding (VRF) table. About VRF-lite VRF-lite is a feature that enables a service provider to support two or more VPNs, where IP addresses can be overlapped among the VPNs. VRF-lite uses input interfaces to distinguish routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be either physical, such as Ethernet ports, or logical, such as VLAN SVIs, but a Layer 3 interface cannot belong to more than one VRF at any time. Terminology ·  ...
1 comment
Read more

Flex VPN

Cisco FLEX VPN with IKEv2 Large customers deploying IPSec VPN over IP networks are faced with high complexity and high cost of deploying multiple types of VPN to meet different types of connectivity requirements. Customers often have to learn different types of VPNs to manage and operate different types of network. And once a technology is selected for a deployment, migrating or adding functionality to enhance the VPN is often avoided. FlexVPN was created to simplify the deployment of VPNs, to address the complexity of multiple solutions, and as a unified ecosystem to cover all types of VPN: remote access, teleworker, site to site, mobility, managed security services, and others. Cisco IOS FlexVPN Features and Benefits: Cisco IOS FlexVPN is a unified VPN solution and provides the following benefits: ●     Scalability:  IKEv2 provides scalability feature with the help of IKEv2 Proposal, in which we can use multiple integrity, encryption & DH...
Post a Comment
Read more

Introduction to Segment Routing

Segment Routing Introduction Before we proceed to understand the segment routing technology, we must understand that SR is a technology and every technology has made for a solution. So, first, we need to understand the solution and its need. All the Service providers are facing following issues with current infrastructure: 1.     A lot of manual configuration for reserving the path in the SP Core network for a different type of traffics. 2.     Lack of application-level visibility which leads to classifying network based on only IP, Port and QoS classification. 3.     Lack of application integration with the network. 4.     No centralized control over the path based on different type of services. 5.     No end-to-end visibility from Data Center to an End user, which leads to sub-optimal paths for application in different domains. 6.     The separate signaling protocol is r...
2 comments
Read more