Let’s continue our discussion about GRE tunnels. If you didn’t read the article related to GRE, I would recommend you take a look at the “Step-by-Step : Understanding GRE Tunnels” article.

In this section we will improve the topology we built in the previous post, by adding a security layer with IPSec.

As a reminder, we already set up the following infrastructure:

  • A simple GRE tunnel between Branch-1 and Branch-2 with their respective Serial interface as endpoints.


Why use GRE over IPSec instead of pure IPSec tunnels?

There are several benefits of using GRE tunnels alongside IPSec, primarily because IPSec does not support traffic other than unicast. This can lead to issues if you plan to use services that require such type of traffic, such as routing protocols like OSPF or EIGRP.

Thanks to the GRE encapsulation process, broadcast and multicast traffic are encapsulated into a unicast packet that can be treated by IPSec, making dynamic routing possible between peers separated by an insecure network area.

You may simply be willing to implement IPSec if you wish to benefit from GRE strengths and are concerned with privacy (remember that GRE does not encrypt traffic). Also, GRE tunnels provide a higher level of resiliency than IKE keepalives actually do.



Of course, there are several disadvantages of using this kind of solution, consider the following before getting hands on technical stuff:

  • Using GRE consumes bandwidth and impacts performances. Adding encryption may even more alter processing resources and increase network latency. Ensure your infrastructure will support it.
  • ACL entries need to be manually maintained, which can become tedious for medium-large sized companies.
  • Using Point-to-Point GRE-over-IPSec tunnels does not scale well. If you plan to add multiple remote sites, consider implement other solutions such as DMVPN, which dynamically builds tunnels between remote peers while reducing the administrative management tasks.


1- Implementation

Note: In order to benefit from IPSec crypto features, ensure that your IOS version supports them. You can use the Cisco Feature Navigator tool in order to get a complete list of the supported features at

IKE Phase 1

The IPSec options used by effective communications are defined in a transform set. In this configuration example, we use both AH and ESP with AES for encryption, and SHA for respective integrity checks:

Branch-1 Branch-2
crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac

crypto map IPSEC_MAP 10 ipsec-isakmp
set peer
set transform-set STRONG
match address IPSEC_ACL

ip access-list extended IPSEC_ACL
permit gre host host

Interface Serial0/0
crypto map IPSEC_MAP

crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac

crypto map IPSEC_MAP 10 ipsec-isakmp
set peer
set transform-set STRONG
match address IPSEC_ACL

ip access-list extended IPSEC_ACL
permit gre host host

Interface Serial0/1
crypto map IPSEC_MAP

The interesting traffic that needs to be encrypted through the tunnel is the traffic that matches the IPSEC_ACL. Now we can simply group all of the tunnel’s options into a crypto-map, by defining the remote peer address andwhich traffic must be encrypted by which specific transform set. The ISAKMP policy is not specified in the crypto-map since it is related to ISAKMP phase 1 and negotiated depending on each endpoint’s configuration.

The IPSEC_ACL has to be mirrored between the 2 endpoints. In order words, the traffic you need to encrypt has to be accepted on the other side. As a result, simply switch the source and destination sections for each entry on both routers. You will notice that we match traffic exiting the physical interface: we specify GRE as the traffic type and the source / destination addresses of the Tunnel

Finally, the crypto-map is applied on the physical interface. Note that applying the map on the Tunnel interface may not work as expected.

The following log message should be raised:




You can verify and troubleshoot the phase 1 and 2 SA by issuing ‘show crypto isakmp sa‘ and ‘show crypto ipsec sa‘, respectively.

Branch-1 (ISAKMP)
Branch-1#show crypto isakmp sa
dst src state conn-id slot status QM_IDLE 1001 0 ACTIVE


The second command can help monitor how many packets have been traveling through the tunnel:


Branch-1 (IPSec, excerpt)
Branch-1#show crypto ipsec sa
interface: Serial0/0
Crypto map tag: IPSEC_MAP, local addr

protected vrf: (none)
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
current_peer port 500
PERMIT, flags={origin_is_acl,}
  #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
  #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0


If we take a look at how packets look like:


Note that the ping from to travels to its destination as an encapsulated packet that is authenticated (AH) and encrypted (ESP) according to the settings configured above.

Note: Some interesting traffic needs to be generated before the tunnel is fully operational. If you are working on a lab environment, you can snif the ISAKMP traffic and observe how the exchange process works.

This article is intended to share knowledge. If you find something missing, or that should be improved, I would be pleased to add such information.


Submit a Comment

Your email address will not be published. Required fields are marked *

Let’s connect today

© 2019 Pierre Collard. All rights reserved. Solutions Architect Consultant at EVA GROUP.

Privacy Policy