Encrypted GRE Tunnel with IPSEC

Lessons Discussion
80

Hello @lagapides

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!

81

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

82

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

83

Hello Samir

The purpose of this access list is to identify what traffic must be encrypted using the crypto map. This access list must match user traffic. If we want to encrypt anything and everything that goes over the GRE tunnel, then we must use an access list that matches everything. This is why we use the any any keywords.

If you were to use the access list you suggest, then nothing will be encrypted. This is because the access list matches tunneled traffic, that is, the IP headers of the packets encapsulated inside GRE. The IP addresses in your ACL are on the IP header of the outside or encapsulating IP packet.

Yes, this is the case. You can see how this is done in the following lesson:

Why are there different approaches? Well, using a profile is considered a newer and simpler way to implement it. Using a crypto map and access list is the “older” way. It’s just a matter of evolving technologies and implementations. If the equipment supports it, using the new way is much simpler and less prone to errors, so it is preferable.

I hope this has been helpful!

Laz

84

Hi Lazaros,

Let me have a think, because I actually created a lab and it seems that using GRE tunnel IP addresses to identify the traffic works, but I might be wrong.

In the meantime, I think I noticed a typo in the lesson Cisco IPsec Tunnel Mode Configuration:

Last but not least, we’ll activate the crypto map on the interface:

R1(config)#interface fa0/0
R1(config-if)#crypto map CRYPTOMAP

But according to the toplogy diagram R1’s interface is Gi0/1.

Thanks,

Sam

85

Hello Samir

Thanks for pointing out the typo, I’ll let Rene know to make the corrections.

As for the lab, check it out and get back to us with your results.

I hope this has been helpful!

Laz

1 Like
86

Hi Laz,

I labbed this up and it does appear that the IP of the GRP packet is being matched, not the traffic in the tunnel itself:

My config for R3 is as follows:

crypto isakmp policy 1
 encr aes
 hash md5
 authentication pre-share
 group 14
!
crypto isakmp key CCNP address 192.168.12.1   
!
crypto ipsec transform-set TRANS esp-aes esp-md5-hmac 
 mode tunnel
!
crypto map MAP 10 ipsec-isakmp 
 set peer 192.168.12.1
 set transform-set TRANS 
 match address 100
 !
access-list 100 permit gre host 192.168.23.3 host 192.168.12.1
access-list 100 permit gre any any
!
interface Tunnel0
 ip address 192.168.13.3 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.12.1
!
ip route 172.16.1.0 255.255.255.0 192.168.13.1

I successfully pinged using loopbacks as the source and destination and ran a sniffer on the link at the same time, which shows ESP packets.

And here is the access list on R3:

Extended IP access list 100
    10 permit gre host 192.168.23.3 host 192.168.12.1 (74 matches)
    20 permit gre any any

Thanks,

Sam

87

Hello Samir

My apologies, my previous post was incorrect. It is the IP addresses of the GRE tunnels that are being matched here, not the tunneled traffic itself. So you could indeed specify the specific tunnel addresses in the ACL and the result would be the same.

Just a note here, in your configuration above, it seems that you are permitting specific hosts (the tunnel IP addresses) but in your second ACL statement you are permitting everything, which is redundant. You can either permit everything, or choose to permit only the addresses of the tunnels. In any case, the result is the same…

I hope this has been helpful!

Laz

88

Hi,

Thanks for clearing that up.

I actually created the second ACL intentionally, to make the sure the tunnel worked before checking which of the two permit statements was actually being used.

Thanks again,

Sam

1 Like
89

Hi,

I stumbled upon an issue when I tried to implement this.
When I try to apply the crypto map to the interface, my ospf configuration stops working.
The interface thats connected and my tunnel changes it’s state to down.
Any idea on why that could happen?

Kind regards

90

Hello Muhammed

The only situation in which I can think of that this would happen is if you haven’t implemented the static routes between the Branch, ISP, and HQ. You’ll notice at the very beginning Rene creates static routes between these three routers in order for communication to take place between all three for the purpose of establishing the tunnel.

If you have configured these routers to share these routes via OSPF (specifically the 192.168.12.0/24 and 192.168.23.0/24 subnets) then once you enable the tunnel, you will get what is called a GRE tunnel recursive routing error, where OSPF neighbors will be dropped, and the tunnel fails.

More information about this error can be found at this lesson:

Check to see if that is the case. If not, give us some more information so we can help you with the troubleshooting process…

I hope this has been helpful!

Laz

91

Hi,

Can you explain how works IPSEC with NAT-T?

Thanks

92

Hello Giovanni

Take a look at this Cisco community forum thread that explains this in detail.

You may also find this post helpful:

I hope this has been helpful!

Laz

93

how come you dont add a HASH here?

HQ(config)#crypto isakmp policy 10
HQ(config-isakmp)# encr aes 256
HQ(config-isakmp)# authentication pre-share
HQ(config-isakmp)# group 5
HQ(config-isakmp)# lifetime 3600

On your DMVPN post you setup same thing but add the HASH:

I am working in live environment and I saw one side had HASH of SHA and saw some co-workers building another side and didn’t put in HASH.

Since they was using a template (Mail Merge) I figured if you left HASH out it might just automatically default to the standard otherwise their mail merge template would have not worked in the past but was unsure so just to be safe I asked them to put it in.

I saw the HUB side had a HASH of SHA in the Crypto isakmp policy 10 and figured could be possibility of mismatch if not added but not sure.

So just curious.

94

Hello Brian

The hash command under the IKE policy is used to specify the hash algorithm to be used within that policy. The default is SHA, which means if you don’t specify it, SHA is configured. This is why the specific implementation you described works, because one end is explicity configured as SHA, and the other is by default SHA. In the case of the DMVPN over IPSec lesson, a non-default configuration of sha256 was chosen, and that is why the command appears.

For more info about the hash command under the IKE policy configuration mode, take a look at this Cisco command reference:

I hope this has been helpful!

Laz

95

Yes that helps confirm what I thought. It always makes me feel better to get confirmation of how the world works well in this case some theory on networking IKE!

Thanks,

1 Like
96

Hi Team,
what would be the difference between applying the crypto map to the tunnel interface vs the ethernet interface? Both seem to work?

Cheers

97

Hello Shashank

When you apply the crypto map on the tunnel interface, you are employing IPSec over GRE while when you apply it on the physical interface, you are employing GRE over IPSec. Yes both seem to work, but they do different things.

Take a look at this Cisco Community post that further describes this situation in more detail.

I hope this has been helpful!

Laz

98

Hello, everyone!

I have a short question. Let’s say that I have a few geographically distinct sites that I want to enable connectivity between.

Which option is generally better? Configuring IPSec VPNs or purchasing an MPLS service from the service provider?

Ever since my CCNA studies, I’ve been wondering in what situations IPSec VPNs over the Internet would be more preferable than MPLS.

What are some things that we should take into consideration here, please? On what basis should we decide whether we want MPLS or IPSec VPNs or even our own dedicated connection (leased line) to connect our various sites?

Thanks!

99

Hello David

As with many of these choices, it primarily comes down to a balance between service and cost. If you only have a few sites, and each site has few users, then cost-wise, it’s preferable to use IPSec VPNs. If you have many sites with many users and you need a high level of administration and coordination to set all of this up, then it would probably cost less to go with a service provider’s offering of MPLS since you won’t have to deal with configuration and maintenance.

These are the two extremes. However, additional characteristics that you should take into account for each case include:

IPSec VPNs

  • They’re free (assuming you already have the Internet connection and the appropriate equipment)
  • They can be set up and torn down by you or your staff so you have full control
  • They’re typically easy to set up and manage, assuming you have a small number of sites.

MPLS

  • It’s a service you typically have to purchase from a provider, so there is a cost
  • It’s a black box for you so you don’t have to configure anything, it’s all taken care of by the service provider

Both choices are safe and typically will provide you with what you need. However, you should also consider other options as well including:

  • DMVPN
  • FlexVPN
  • SD-WAN

Leased lines are very rare today because they are very expensive (since they require a dedicated circuit) and because other WAN technologies such as those mentioned are much more flexible.

I hope this gives you an overview of the kinds of things you should keep in mind when choosing a WAN technology for your particular scenario.

I hope this has been helpful!

Laz