Question about GRE

So, I've thought long and hard about this and am looking for some help.

If you have a VPN between sites and are using OSPF, you're going to need to use GRE. OSPF uses multicasts which are not supported through IPSec VPN tunnel. GRE does support it.

So, transport mode is typically used instead of tunnel mode. Normally, ESP would encapsulate the entire packet in tunnel mode, and it would be encrypted with whatever your policy defined. However, you can set a tunnel interface to use GRE. My confusion from this configuration I'm looking at is that the transform set mentions ESP being used. My understanding though is that GRE will use your IPSec transform set to secure the packet. For example, GRE will encapsulate the entire packet and it can be encrypted using AES. What exactly is happening next? ESP in transport mode will only encrypt the payload, but my understanding is that the packet has already been encapsulated with GRE and encrypted. So what exactly am I not understanding here? Hopefully I'm not too far off on my understanding. I understand why we're using GRE, but I want to know exactly how it works. After all, we are using transport mode, and yet GRE still encapsulates the entire packet. Please help.

I could walk about from this just knowing that GRE needs to be used if you're going to be using a routing protocol over your VPN, and that transport mode saves overhead. I believe understand encapsulating & encrypting the entire packet (aka tunnel mode) will protect the source/destination of the local addresses, and throw on the source/destination public IPs in the new header. So I do not think tunnel mode is the killer for me. It's more just looking to see what exactly happens in a GRE transport tunnel. If ESP is listed in the transform set, ESP must be encapsulating the packet still, and then GRE must be encapsulating that and then encrypted. That seems unlikely/un-necessary to me, so I'm believing my understand is not correct.

Find more posts tagged with

Comments

Hondabuff

Instead of using GRE that adds a header, Use a VTI tunnel that uses a IPsec Profile. Then you can use a routing protocol over the Tunnel. So if you have a packet that's destined to a device on the network discovered on the other side of the tunnel from the routing protocol. It will go out the Tunnel and auto-magically gets encrypted by the transform set that was called out by the IPsec profile. A lot easier to setup and you don't need access lists. Long story short, IPsec traffic gets encapsulated with the GRE header so it can be routed. Requires you to make the MTU size smaller which requires more CPU cycles to send a file. A Good read for you. Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode - What's the Difference?

1) Make a Transform Set
2) Make an IPsec Profile and set the Transform set name.
3) Make your Isakmp key and set peer address.
4) Set your Isakmp policy " HAGLE"
5) Create a Virtual tunnel and assign it a IP address or IP unnumbered
6) Set the tunnel mode
7) Set the tunnel to use the profile set from step 2

Setup a routing protocol and advertise the routes including the VTI tunnel.

This is the method I use.
Configuring Point-to-Point GRE VPN Tunnels - Unprotected GRE & Protected GRE over IPSec Tunnels

hurricane1091

I actually did read that first link, but I do appreciate your reply. I'm not so sure about VTI but I did briefly come across it during my Google adventure today. Your tutorial link (thank you for that) is using a VTI, no? It's still using GRE though, correct?

My understanding is that the router I am working with has a VTI, but a sh int 'tunnel name' reveals "Tunnel protocol/transport GRE/IP"

So when you say instead of using GRE that adds a header, use a VTI tunnel instead, I get confused since is it would appear I am doing a VTI with GRE and GRE cannot be avoided if you want to use routing protocols over the VPN.

I'm not far into the CCNP book and probably shouldn't be digging this deep at work, but I'm just really curious.

Hondabuff

A VTI will become a GRE only with the "R1(config-if)#tunnel mode gre ip" Command. Kinda like a "switch command"
This will make it add the GRE header. The other way I use is new method "R1(config-if)#tunnel mode ipsec ipv4" so it takes advantage of the new VTI tools and tells the tunnel to encapsulate all traffic going across it.

1. Dynamic routing and multicast through VTI!Remember one nasty limitation of IPSec - no multicast through unless you used GRE?Getting devices to talk to each other via OSPF or EIGRP required some tweaks.Now it's available by default!That being said GRE is not out of the picture, it's still broadly used and more flexible is more-than-one-better.
2. No GRE overhead.Have a ping with df-bit set over your tunnel interface when it's VTI and GRE over IPSec...For example:ping TUNNEL_IP_ON_THE_OTHER_SIDE source tunnel X df-bit size 1436
3. Tunnel protection and tunnel mode...Two commands that make VTI.tunnel mode ipsec ipv4 (or ipv6!)tunnel protection ipsec profile PROFILE_NAMEYes, no need to put in an access-list to create a tunnel.And, no, you don't need to have crypto map applied anywhere!
4. Per-interface/per-tunnel features.QoS, uRPF, CBAC/ZBF, PBR, access-lists anyone?5. SVTI to DVTI IPSec tunnel.You can have SVTI spokes connecting to DVTI hub location and still utlize above benefits. - See more at: https://supportforums.cisco.com/blog/149426/advantages-vti-configuration-ipsec-tunnels#sthash.zZuJqznM.dpuf

Hondabuff

Here is where you can see the command change the tunnel.

Branch-R1#sho int tun 0
Tunnel0 is up, line protocol is down
Hardware is Tunnel
Internet address is 172.16.1.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.2 (Serial0/0), destination 200.0.0.2
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "P1")
Last input never, 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: 0
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
0 packets input, 0 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
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Branch-R1#
Branch-R1#
Branch-R1#
Branch-R1#
Branch-R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch-R1(config)#int tun 0
Branch-R1(config-if)#tunnel mode gre ip
Branch-R1(config-if)#^Z
Branch-R1#wr
Building configuration...
*Mar 1 00:01:47.355: %SYS-5-CONFIG_I: Configured from console by console[OK]
Branch-R1#
Branch-R1#
Branch-R1#sho int tun 0
Tunnel0 is up, line protocol is down
Hardware is Tunnel
Internet address is 172.16.1.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.2 (Serial0/0), destination 200.0.0.2
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 "P1")
Last input never, 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: 0
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
0 packets input, 0 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
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out

hurricane1091

Okay, thank you. Makes more sense. Since GRE is mentioned in the CCNP book and we're using it at work, I'm going to go lab this up. Best part of working here is that I'm always able to go lab it out.

If you use GRE though, how does ESP still work into the picture?

Hondabuff

Protocol 50 on Port 500 for ESP packets. Part of your IKE phase 1 of the tunnel.

Branch-R1#sho cry session
Crypto session current status
Interface: Tunnel0
Session status: DOWN-NEGOTIATING
Peer: 200.0.0.2 port 500
IKE SA: local 100.0.0.2/500 remote 200.0.0.2/500 Inactive
IKE SA: local 100.0.0.2/500 remote 200.0.0.2/500 Inactive
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map

Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 200.0.0.2 port 500
IKE SA: local 100.0.0.2/500 remote 200.0.0.2/500 Active *Sending and receiving SA's on port 500*
IKE SA: local 100.0.0.2/500 remote 200.0.0.2/500 Active
IKE SA: local 100.0.0.2/500 remote 200.0.0.2/500 Inactive
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 4, origin: crypto map
Branch-R1#
*Mar 1 00:00:46.491: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Mar 1 00:00:47.151: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Tunnel0 from LOADING to FULL, Loading Done

Branch-R1#sho cry isa sa
dst src state conn-id slot status
100.0.0.2 200.0.0.2 QM_IDLE 1 0 ACTIVE
200.0.0.2 100.0.0.2 QM_IDLE 2 0 ACTIVE
200.0.0.2 100.0.0.2 MM_NO_STATE 0 0 ACTIVE (deleted)

Branch-R1#sho cry ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 100.0.0.2
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 200.0.0.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 13, #pkts encrypt: 13, #pkts digest: 13 *Shows that the tunnel is encap/decapsulating*
#pkts decaps: 12, #pkts decrypt: 12, #pkts verify: 12
#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.: 100.0.0.2, remote crypto endpt.: 200.0.0.2
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x2D7C750E(763131150)
inbound esp sas:
spi: 0x7B53DB8C(2069093260)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4379978/3577)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
spi: 0xFB4121DC(4215349724)
transform: esp-aes esp-sha-hmac , Tells what encryption strength to use for the esp packet.
in use settings ={Tunnel, }
conn id: 2003, flow_id: SW:3, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4388596/3569)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x1D152898(487925912)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: SW:2, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4379978/356

IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
spi: 0x2D7C750E(763131150)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2004, flow_id: SW:4, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4388595/3563)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:

Dieg0M

The other option is not to use GRE. OSPF does not need to use multicast for adjacency and database exchange.

Hondabuff

Dieg0M wrote: »

The other option is not to use GRE. OSPF does not need to use multicast for adjacency and database exchange.

I tried to read between the lines and do some research "non-multicast for OSPF" and I feeling I'm on a snipe hunt. What tid-bit of info did you pick up somewhere that you can share about OSPF not being multicast?

d4nz1g

(config-if)# ip ospf network point-to-point non-broadcast [or something like that]

router ospf xx
neighbor x.x.x.x

Hondabuff

d4nz1g wrote: »

(config-if)# ip ospf network point-to-point non-broadcast [or something like that]

router ospf xx
neighbor x.x.x.x

ohh, frame relay again

I thought I was missing out on some cool new feature that I overlooked.

hurricane1091

My boss made me lab up a regular VPN, which I've done. I'll do a DMVPN next, but my question really is how is traffic identified? With a regular VPN, you create an ACL and bind it to a crypto map. Everything makes sense there. In this DMVPN world, you create a tunnel interface. In our case here, the DMVPN is the backup link. I am assuming everything that goes over that link is encrypted. I need to dig deeper into this lol.

Hondabuff

hurricane1091 wrote: »

My boss made me lab up a regular VPN, which I've done. I'll do a DMVPN next, but my question really is how is traffic identified? With a regular VPN, you create an ACL and bind it to a crypto map. Everything makes sense there. In this DMVPN world, you create a tunnel interface. In our case here, the DMVPN is the backup link. I am assuming everything that goes over that link is encrypted. I need to dig deeper into this lol.

Traffic is defined by static route or learned by IGRP. As soon as the data hits the tunnel it gets encrypted. I hated the old ACL/Crypto map method.