Encrypted GRE Tunnel with IPSEC

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

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?

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

1 Like

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.

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

1 Like

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?

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:

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

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 :slight_smile: - 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

1 Like

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?

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

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

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

Hi All! I’m little bit confused, i’m configuring a routed based vpn, GRE tunnel for a ASA and a Router with both Ipsec in my test enviroment. Do a still need a interesting traffic ACL and do i also need to exempt traffic from noNat or Overload, this is needed for a policy based vpn configuration (Anyconnect or site to site)?

Hello Carlos

Cisco ASAs do not support GRE tunnels, but they do support VTIs if you want to enable routing. Can you clarify what you want to accomplish so that we can answer your questions based on that?

Thanks!

Laz

HI Laz,
Sorry for my late response. Thanks for the shared link regarding configuring GRE for routers.
Hopefully i can clarify my Question regarding the following :sweat_smile::
Do i still need to configure a a Interesting traffic ACL or to exempt NAT for A route based policy
(VTI - ASA or GRE - Routers). Because for policy based VPN (routers or asa) a need to configure a Interesting traffic ACL or to exempt NAT, and for a routed based i can care this with a ip route or routed protocol.:grinning:

Thanks!

Hello Carlos!

When creating a VTI, you are correct in that you don’t require the use of an access list to specify interesting traffic like you would when configuring IPsec tunnel mode. Also, as you state, NAT exemption is not necessary from the moment you have a VTI which is routing based. You can find out more about VTIs on IOS at the following lesson:

I hope this has been helpful!

Laz

Hey, when I tried to setup the Encrypted GRE tunnel and then form OSPF neighbor adjacency between my R1 and R3, I got the following error message:

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
        (ip) vrf/dest_addr= /192.168.12.1, src_addr= 192.168.23.3, prot= 47

But, when I tried setup the OSPF neighbor adjacency first and then setup the Encrypted GRE tunnel it all went perfectly fine.
Is there any reason for that?

Hello Inon

The error that you show above indicates that a packet reached the destination without using the IPsec encrypted tunnel. This has to do with the routing that you have configured. I’m not sure if the issue is due to the order in which you have applied OSPF, but keep in mind that you have static routing as well as OSPF routing available between HQ and Branch. If a packet is routed via the static route without using the tunnel interface, then it won’t be encrypted. If it is routed via the tunnel interface, then it will be encrypted. When the error appears, check out the following:

  1. Check the routing table and ensure that correct routing is in place to route packets between the endpoints via the tunnel
  2. Check that the OSPF neighbor relationship is being created successfully
  3. Test using some pings and traceroute to see what route is actually being taken.

In this way, you can verify why certain packets were routed outside of the tunnel. My feeling is that there was an error in the configuration beyond just the order in which the features were applied. Take a look and let us know!

I hope this has been helpful!

Laz

In my situation, my main branch router needs to connect a 3rd party vendor router via Encrypted GRE tunnel, also my main branch router needs to connect to different 3rd party vendors via just IKE/IPSEC site to site VPN tunnel. In that case, can i use the same CRYPTO MAP for both the purposes?

Hello Mathana

Yes, you should be able to use the same crypto map for both the encrypted GRE tunnel and the IKE/IPSEC tunnels. It is possible to create two or more tunnels using the same crypto map.

I hope this has been helpful!

Laz