Encrypted GRE Tunnel with IPSEC

[ReneMolenaar]

@Sean it is possible to encrypt GRE traffic on your ASAs where the routers are sitting behind your ASAs. What kind of access-list are you using to match your GRE traffic? You should use something like this:

access-list GRE extended permit gre host x.x.x.x host y.y.y.y

Where x.x.x.x and y.y.y.y are the IP addresses of your routers that are used to establish the GRE tunnel.

@Sina the more you do it, the easier it becomes. Some stuff like L2/L3 I do often enough to keep everything fresh in my memory. Other things (like IPsec) I also have to look up sometimes. It’s best to keep something like a notebook for yourself with notes/examples so that you can quickly look up something. Evernote works well for this.

[chihchengk]

Hi Rene,

Thank you for your excellent explanation!!! Can you add IKEv2 configuration? That will be great to learn since it was out in 2005.

[shantel]

19 posts were merged into an existing topic: Encrypted GRE Tunnel with IPSEC

[Zaman.rubd]

Dear Rene,
Thanks for your nice article as always.
I am little bit confused about your two article “Encrypted GRE Tunnel with IPSEC” and GRE over IPSEC . What is the basic/ main difference between two ?? Pls help me to understand it clearly .Thanks
Br/zaman

[lagapides]

Hello Mohammad.

What exactly is meant by each of the two phrases depends on the context. Encrypted GRE Tunnel with IPSec refers to the encryption of the information sent over a GRE tunnel using the functionalities of IPSec. GRE over IPSec is not that specific and it depends on what the person speaking really means.

IPSec used in combination with GRE can function in two ways, either in tunnel mode, or transport mode.

Tunnel mode, which is the default, which is also what Rene has configured in the lesson, the whole GRE packet is encapsulated and encrypted within the IPSec packet.

Transport mode on the other hand, involves the encapsulation of only the GRE payload. The GRE header in this case is not encrypted.

Take a look at this post by Rene for more details.

I hope this has been helpful!

Laz

[hussien.samer]

Hi Rene,

Can you give me an example about how to configure both ipsec AH only and ipsec AH combined with ESP ( in wireshark I can see both AH & ESP ) just like you describe in IPsec (Internet Protocol Security) lessons ??
and I need another example about how to use virtual tunnel interfaces instead of the crypto map ??

[ReneMolenaar]

Hi Hussein,

The only thing you have to change is the transform set:

R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET ?
  ah-md5-hmac      AH-HMAC-MD5 transform
  ah-sha-hmac      AH-HMAC-SHA transform
  ah-sha256-hmac   AH-HMAC-SHA256 transform
  ah-sha384-hmac   AH-HMAC-SHA384 transform
  ah-sha512-hmac   AH-HMAC-SHA512 transform
  comp-lzs         IP Compression using the LZS compression algorithm
  esp-3des         ESP transform using 3DES(EDE) cipher (168 bits)
  esp-aes          ESP transform using AES cipher
  esp-des          ESP transform using DES cipher (56 bits)
  esp-gcm          ESP transform using GCM cipher
  esp-gmac         ESP transform using GMAC cipher
  esp-md5-hmac     ESP transform using HMAC-MD5 auth
  esp-null         ESP transform w/o cipher
  esp-seal         ESP transform using SEAL cipher (160 bits)
  esp-sha-hmac     ESP transform using HMAC-SHA auth
  esp-sha256-hmac  ESP transform using HMAC-SHA256 auth
  esp-sha384-hmac  ESP transform using HMAC-SHA384 auth
  esp-sha512-hmac  ESP transform using HMAC-SHA512 auth

For example, if you want to use AH:

R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac

or ESP:

R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac

or ESP+AH:

R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET esp-sha-hmac ah-sha-hmac esp-aes

If you want to test this, change the transform-set and then clear the current SA:

R1#clear crypto sa

You can verify if you are using ESP/AH by looking at the SA. For example, here’s ESP:

R1#show crypto ipsec sa | begin inbound esp
     inbound esp sas:
      spi: 0x52BDAEFA(1388162810)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 5, flow_id: SW:5, sibling_flags 80004040, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4241877/3557)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x7D2533B3(2099590067)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 6, flow_id: SW:6, sibling_flags 80004040, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4241877/3557)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

Above you see that it only shows inbound/outbound ESP, nothing at AH.

Here’s AH:

R1#show crypto ipsec sa | begin inbound ah
     inbound ah sas:
      spi: 0xC412FE1D(3289579037)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 7, flow_id: SW:7, sibling_flags 80004050, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4189277/3584)
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:
      spi: 0xBF33F950(3207854416)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 8, flow_id: SW:8, sibling_flags 80004050, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4189277/3584)
        replay detection support: Y
        Status: ACTIVE(ACTIVE)
          
     outbound pcp sas:

Above you only see inbound/outbound ESP, no AH.

Here is AH+ESP:

R1#show crypto ipsec sa | begin inbound
     inbound esp sas:
      spi: 0xD68D5E92(3599589010)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 9, flow_id: SW:9, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4298169/3577)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:
      spi: 0x58397E06(1480162822)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 9, flow_id: SW:9, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4298169/3577)
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound pcp sas:

     outbound esp sas:
      spi: 0x2CA509F3(749013491)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 10, flow_id: SW:10, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4298169/3577)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)
          
     outbound ah sas:
      spi: 0x110A4D8E(285887886)
        transform: ah-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 10, flow_id: SW:10, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
        sa timing: remaining key lifetime (k/sec): (4298169/3577)
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

Here is a quick example for a virtual tunnel interface. I’ll turn this one into a lesson later:

Here are the configs of the routers.

R1:

hostname R1
!
ip cef
!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key MY_PASSWORD address 10.10.10.2     
!
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
 set transform-set MY_TRANSFORM_SET 
!
interface Tunnel0
 ip address 12.12.12.1 255.255.255.0
 tunnel source 10.10.10.1
 tunnel mode ipsec ipv4
 tunnel destination 10.10.10.2
 tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/1
 ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 10.10.10.1 255.255.255.0
!
ip route 192.168.2.0 255.255.255.0 Tunnel0
!
end

And R2:

hostname R2
!
ip cef
!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key MY_PASSWORD address 10.10.10.1     
!
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
 set transform-set MY_TRANSFORM_SET 
!
interface Tunnel0
 ip address 12.12.12.2 255.255.255.0
 tunnel source 10.10.10.2
 tunnel mode ipsec ipv4
 tunnel destination 10.10.10.1
 tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/1
 ip address 192.168.2.254 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 10.10.10.2 255.255.255.0
!
ip route 192.168.1.0 255.255.255.0 Tunnel0
!
end

The main difference is that we don’t use a crypto-map anymore. We still have a crypto isakmp policy and a transform set. What is new is that we have a crypto ipsec profile that refers to our transform-set. We also use a tunnel interface where we refer to our IPSec profile and where Ipsec is enabled.

The tunnel interface now shows IPSEC/IP:

R1#show interfaces tunnel 0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 12.12.12.1/24
  MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 10.10.10.1, destination 10.10.10.2
  Tunnel protocol/transport IPSEC/IP

We can verify that it works:

R1#show crypto session 
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE     
Peer: 10.10.10.2 port 500 
  Session ID: 0  
  IKEv1 SA: local 10.10.10.1/500 remote 10.10.10.2/500 Active 
  Session ID: 0  
  IKEv1 SA: local 10.10.10.1/500 remote 10.10.10.2/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 6, origin: crypto map

Hope this helps!

Rene

[hussien.samer]

Thanks Rene, that help indeed.

[ReneMolenaar]

I now have a complete example with dynamic VTI and static VTI here:

IPSec VTI Virtual Tunnel Interface | NetworkLessons.com

[lodown31]

I am labbing the above and I have a question… concerning the “access-list 100 permit gre any any” command. When I have this command in there, I see encaps and decaps in the “show crypto ipsec sa” command. However, if I change the “any any” to both of the LAN subnets, I no longer see encaps and decaps. I am using GNS3 with an IOS for a 3660 router. Is this a bug? Or am I doing something wrong?

[ReneMolenaar]

Hi John,

Think of the source and destination addresses of the GRE tunnel. Those are not the IP addresses of your LANs but the IP addresses of the routers that establish the GRE tunnel. For the routers in my lesson that would be:

HQ:

permit gre host 192.168.12 host 192.168.23.3

Branch:

permit gre host 192.168.23.3 host 192.168.12.1

Hope this helps!

Rene

[wilder7bc]

Hi Renee,

Just review of some static route Information. You used:

HQ(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2

does not the 255.255.255.255 mean that every octet is a network?

I guess this static route is setup different than the basic one? meaning its normally:

Network your trying to reach. Then its the subnet mask and then the next hop address.

It threw me off that 192.168.23.2 was an actual host instead of a network like 192.168.23.0.

I am use to seeing it like the following:

ip route 192.168.23.0 255.255.255.0 192.168.12.2

I am rusty on some of this stuff and its just probably something I don’t remember clearly but was hoping you could give me a brief summary. My guess is that the 255.255.255.255 means treat it specifically as a address in other words if we did not use the /32 then we could not add the specific IP address. I just wanted to conformation of my thoughts or the correction of them to be more in line with the meaning.

[lagapides]

Hello Brian

When you use the ip route command, what you are telling the router is “in order to get to this network, use this next hop IP.” Now the contents of the command is a network address and a subnet mask. So, if you enter the command

ip route 192.168.23.0 255.255.255.0 192.168.12.2

then what you are saying is that if you get a packet with a destination IP address in the range 192.168.23.1 to 192.168.23.254, send it to 192.168.12.2.

If you change the subnet mask, what you’re doing is essentially modifying the range within which the destination address must fall in order to be routed to the specific next hop address. So if the above command instead was

ip route 192.168.23.0 255.255.255.240 192.168.12.2

then what you are saying is that if you get a packet with a destination IP address in the range 192.168.23.1 to 192.168.23.14, send it to 192.168.12.2.

Now if you use a subnet mask of 255.255.255.255 such as was the case in Rene’s command, then you are just restricting the range to a single IP, or a host address which is equally valid. In the example in this lesson, it makes sense to do so because the goal is for the two branch routers to be able to reach each other’s tunnel source interfaces that correspond to those specific IP addresses. The operation would have worked equally well had he used 255.255.255.0 as the subnet mask.

If you look at the resulting routing table, you should see such static routes as destinations with a /32 prefix, indicating they are indeed hosts.

I hope this has been helpful!

Laz

[vadim.zhukov]

Maybe a little silly question, but - since GRE Tunnel with IPsec configuration goes right after the general IKE/IPSEc theory article, do we need to configure GRE to run encrypted tunnel between two sites? Otherwise why do we need GRE for that at all? Instead of just configuring Ipsec site-to-site tunnel?

And the other silly one - seems crypto map ties up all the encryption scheme, source and destination and shared password, etc, together. Except the isakmp policy for ike phase 1, seems to be . The policy seems is not getting tied up with anything anywhere. Is it just one global policy per router, applied to all the crypto-maps or where does it intersect with the rest of tunnel configuration?

[lagapides]

Hello Vadim

About your first question, it’s important to understand what each entity is and does. GRE is a tunneling protocol. It encapsulates packets and allows them to run over another network. So you can run your internal private IP addresses between two sites that connect to each other over the Internet. A GRE tunnel is not encrypted or secured in any way.

IPSec is a secure network protocol suite that authenticates and encrypts packets. It is a method of encryption and authentication and does not include any tunneling mechanisms. It cannot and will not function on its own. It requires a tunneling protocol to function. So IPSec can be coupled with GRE to create an encrypted tunnel.

So to answer your question:

do we need to configure GRE to run encrypted tunnel between two sites?

Not really, you can use another tunneling protocol. IN the IKE/IPSec lesson, it is the IKE that establishes the tunnel and IPsec that secures/encrypts it. It really comes down to which technology provides you with what you really need/want.

Concerning your second question, the ISAKMP policies function as follows:

Each configuration supports a maximum of 20 ISAKMP policies, each with a different set of values. Assign a unique priority to each policy you create. The lower the priority number, the higher the priority.

When ISAKMP negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peer’s policies against each of its configured policies in priority order (highest priority first) until it discovers a match.

A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established.

This was taken from the following Cisco documentation:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/ike.html#wp1042213

I hope this has been helpful!

Laz

[vadim.zhukov]

Thanks, Lazaros, so ISAKMP policies are indeed not tied to any other configuration (contrary to IPSec portion that are literally point-to-point). There is just a list and it is parsed through by remote peer until it finds the one policy that is the same as configured on it. If none found, negotiation fails. Understood.

Now, as to the second question/explanation, after some digging and chewing, I think Id beg to differ. I got confused because after chapter explaining general IKE/IPsec theory there immediately follows the chapter with configuration of GRE with IPSec. With no chapter providing configuration for just IKE/IPSec. That is a little weird and looks like IPsec tunnels are configured with GRE. But now I see its not the case, simply we jump into additional application of IPsec without addressing configuration of pure IPSec.

Where I beg to differ is your statement that “Not really, you can use another tunneling protocol”. First, we don’t. GRE CAN be used with IPsec, and some other tunneling protocols CAN be used but neither is necessary. IPsec does not need ANY other tunneling protocols. Second, IPsec (and IKE or their combination) IS a tunneling protocol. Tunnel here is defined by a set of parameters included into SA but in the end what is important is that it encapsulates the original data into additional layer, which is particularly obvious in ‘tunneling’ mode with new IP slapped on the packet (so same as in GRE private IP traffic can pass through public network) but even in ‘transport’ mode the original data not just encrypted but encapsulated, which Id say would be definition of a ‘tunnel’. And thats how seems IPsec commonly referred to - ‘IPSec tunnel’. It does not even need IKE to form. While at the same time IKE creates its own ‘tunnel’, not related to IPsec tunnel, though in this case the term ‘tunnel’ probably is less obvious, though still it is ‘tunneling’ , or encapsulating, data that are used for other services (thats IPsec), even if thats only passwords. To further support what Im saying IKE and IPsec ‘tunnels’ may and usually have different lifetimes, so either can expire and disappear while another one is still up. Until I see some definition of a ‘tunnel’ which defies above I say:

1. The IPsec IS a tunnel protocol which does not rely on any other tunnel protocol.
2. IPsec often is combined with another tunnel protocol - IKE, for ease of management. Or may not.
3. IPSec may be used to further encapsulate (and tunnel) another tunnel protocol (like GRE, or mpls…) to add security to them. It also may NEED them in some cases as for example its seems not capable of handling multicasts by itself, so need GRE to do that.
4. IKE is a tunnel protocol that is used to pass information needed to establish a lighter, quicker and more flexible secure tunnels like IPSec. It is not used to pass real data itself as involved mechanisms to establish secure tunnel, namely Diffie-Hellman, are quite intensive and slow, but more convenient (and actually more secure) for delivering for instance shared passwords between two peers than say over the phone.

Just want to note here as well, that I enjoy reading materials provided by Rene, find them quite better than most other on Internet and consider them of great help. But nothing is perfect and in this case it seems a glitch of a sort, with the whole piece of the standard VPN configuration missing. And pretty much answering my own questions sometimes seems a little counterproductive - I would hope for more accurate and detailed answers. Also, would be really nice to have IKEv2 configuration presented as it is quite more complicated while ikev1 is really a legacy features these days.

Thanks

[thiernoamadoubah]

Does the crypto isakmp policy number have to match with the the crypto map number. In this example, they are both 10. If they don’t, how are the parameters of the crypto policy linked to the crypto map?

[lagapides]

Hello Thierno

ISAKMP policies are not tied directly to the crypto map so the numbers don’t have to be the same. ISAKMP policies function as follows:

Each configuration supports a maximum of 20 ISAKMP policies, each with a different set of values. Assign a unique priority to each policy you create. The lower the priority number, the higher the priority.

When ISAKMP negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peer’s policies against each of its configured policies in priority order (highest priority first) until it discovers a match.

A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established.

This was taken from the following Cisco documentation:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/ike.html#wp1042213%201

I hope this has been helpful!

Laz

[vibhumchandorkar]

Hi Everyone,

Does anyone have a working configuration of either GRE over IPSec using Loopbacks OR IPSec using Loopbacks?

It would be much appreciated.

Regards,
Shay Kotian

[lagapides]

Hello Vibhum

You can find some good case studies and examples at this Cisco documentation. It includes an example where a loopback interface is used as a source IP address for a point to point GRE tunnel.

I hope this has been helpful!

Laz