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 
:
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.
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:
- Check the routing table and ensure that correct routing is in place to route packets between the endpoints via the tunnel
- Check that the OSPF neighbor relationship is being created successfully
- 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
Hello,
I set up a laboratory with the IPsec configuration over GRE using the configuration below, the routers have the ios version (12.4 (16)) until then everything went as expected. only loopback traffic triggers encryption, eigrp packets for example are not encrypted.
however I went to run on another model of router version (15.1 (4) M) and in the implementation of the crypto map in the tunnel interface came the following criticism (% NOTE: crypto map is configured on tunnel interface.
** Currently only GDOI crypto map is supported on tunnel interface.)**
for the research I did after version 15.x this config mode is no longer possible.
my doubt is, my intention is to make a configuration, where the encrypted traffic is only the traffic coming from the loopbacks of the router. as was done in my example with the ios 12.4 version.
however I want to do this in version 15.x.
what would be the way to do it from this version 15.x?
Hello Yuri
This is expected behaviour, since the method of implementation has changed from version 12.X to 15.X of IOS. The following Cisco Community information describes these differences in detail:
To take a look at an example of a GRE tunnel encrypted using IPSec for IOS version 15.X, take a look at this lesson:
I hope this has been helpful!
Laz
hi @lagapidis ,
the example you indicated it works by encrypting all the packages that go through the interface!
in my example I just want to encrypt only the traffic originated by Loopbacks. in my scenario the loopbacks are apprehended by the tunnel interface. in the scenario with ios 12.x i can hook the crypto map inside the tunnel interface and inside the crypto map i have the acl allowing only the loopback ip. with that, ipsec is only triggered when there is traffic between these sources.
I don’t want to activate the ipsec with the WAN ip (public) and also not with the tunnel ip.
you see?
Hello Yuri
If you don’t want to encrypt the GRE tunnel, but only want to encrypt loopback traffic, then you can use tunnel mode with an ACL that matches this loopback traffic. An example of this can be found in the following lesson:
The only reason to use GRE with IPSec is if you want to enable a routing protocol over the tunnel and encrypt it. Otherwise, just use IPSec tunnel mode for site to site traffic.
I hope this has been helpful!
Laz
Hi @lagapidis ,
Thanks for the tip! I understand the real role of GRE + IPSEC.
but my question would be if in the scenario with GRE + IPSEC I would be able to have the same operation, just encrypt the desired traffic.
as was done in the scenario I mentioned with IOS in version 12.X.
but I want to do it in version 15.x!
the scenario of the print below I managed to do, however it was with IOS 12.x. thus being able to place the crypto map command directly in the tunnel interface.
in version 15.x I can’t put the crypto map in the tunnel interface, so it doesn’t work
Hello Yuri
Using IOS version 15.x, you can achieve what you want using the configuration in the Cisco IPsec tunnel mode configuration lesson. In this lesson, Rene uses tunnel mode and selects only the traffic he wants to encrypt using the access list. In the lesson, you’ll find that only the traffic between the loopback interfaces is being encrypted.
I hope this has been helpful!
Laz
Hi @lagapidis
OK.
and if I implement a GRE + IPSEC tunnel can I keep only loopbacks being the only encrypted addresses?
what is the config for this?
Hello Yuri
In the Cisco IPsec Tunnel Mode Configuration lesson, Rene configures exactly what you are looking for. Only traffic between the loopbacks is encrypted. This is achieved using the following access-list configuration:
R1(config)#access-list 100 permit ip host 1.1.1.1 host 3.3.3.3
Similarly, this is also configured on R3, with the loopback addresses swapped:
R3(config)#access-list 100 permit ip host 3.3.3.3 host 1.1.1.1
This way, only traffic to and from the two loopbacks is encrypted.
This access list is then referenced in the crypto map called CRYPTOMAP with the command match address 100, and the crypto map itself is applied to the physical interface using the command crypto map CRYPTOMAP.
The result is that any traffic from one loopback to the other will be encrypted, while all other traffic will not.
I hope this has been helpful!
Laz
Hello, @lagapidis
in this example of rene he does not use the GRE config.
only IPSEC is used.
the example I want and with GRE + IPSEC.
Hello Yuri
Sorry for not being more specific, and initially misunderstanding your intent. Using the IOS 15.X implementation of GRE + IPSec, it is not possible to more granularly select traffic to be encrypted beyond using the following access list:
access-list 100 permit gre any any
Specifying particular IP addresses (loopbacks) will not allow you to selectively encrypt traffic. You either encrypt all or non of the GRE traffic. If you want to do this you must use the configuration described in the previous post.
However, you must ask yourself, what is the purpose of doing this? If you are not running routing protocols, then a VTI or IPSec tunnel mode would be the easiest way to go. If you are running routing protocols, it is not necessary, nor functional, to just encrypt traffic between loopbacks.
From my understanding, your question is more due to curiosity, and that’s great as it helps us to learn. But is there a practical reason for which you wanted to implement something like this?
I hope this has been helpful!
Laz
1 Like
Hello @lagapidis
that was exactly what I wanted to know.
in fact it was a laboratory study curiosity!
because I think we should be familiar with all types of implementation!
Thanks a lot for the help!
Hello Yuri
Sorry it took so long to get around to the final answer, but I’m glad you got the answer you were looking for! Always a pleasure to discuss topics with you!
Laz
Hi,
For the access list below from the notes:
HQ(config)#access-list 100 permit gre any any
Would the following also be acceptable?
HQ(config)#access-list 100 permit gre host 192.168.12.1 host 192.169.23.3
Or does it have to be any any?
I have also read that you can encrypt a GRE tunnel by creating an ipsec profile and applying it to a tunnel interface using the tunnel protection ipsec profile command.
Why the different approaches? And which one is best practice?
Thanks,
Sam