Question about GRE

hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
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.

Comments

  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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
    icon_cool.gif 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
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    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.
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    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?
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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/356icon_cool.gif
    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:
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • Dieg0MDieg0M Member Posts: 861
    The other option is not to use GRE. OSPF does not need to use multicast for adjacency and database exchange.
    Follow my CCDE journey at www.routingnull0.com
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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?
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • d4nz1gd4nz1g Member Posts: 464
    (config-if)# ip ospf network point-to-point non-broadcast [or something like that]

    router ospf xx
    neighbor x.x.x.x
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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 icon_sad.gif

    I thought I was missing out on some cool new feature that I overlooked.
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • hurricane1091hurricane1091 Member Posts: 919 ■■■■□□□□□□
    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.
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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.
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
Sign In or Register to comment.