GRE Tunnels are very common amongst VPN implementations thanks to their simplicity and ease of configuration. With broadcasting and multicasting support, as opposed to pure IPSec VPNs, they tend to be the number one engineers' choice, especially when routing protocols are used amongst sites.

The problem with GRE is that it is an encapsulation protocol, which means that while it does a terrific job providing connectivity between sites, it does a terrible job encrypting the data being transferred between them. GRE is stateless, offering no flow control mechanisms (think of UDP). This is where the IPSec protocol comes into the picture.

IPSec’s objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality. IPSec is extensively covered in our IPSec protocol article. 

IPSec can be used in conjunction with GRE to provide top-notch security encryption for our data, thereby providing a complete secure and flexible VPN solution. IPSec can operate in two different modes, Tunnel mode and Transport mode.  Both of these modes are covered extensively in our Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode article. Additionally, Cisco GRE Tunnel configuration is covered in our Configuring Cisco Point-to-Point GRE Tunnels. We highly recommend reading these articles before proceeding as it is a prerequisite for  understanding the information covered here.

As with IPSec, when configuring GRE with IPSec there are two modes in which GRE IPSec can be configured, GRE IPSec Tunnel mode and GRE IPSec Transport mode.

This article examines the difference between GRE IPSec Tunnel and GRE IPSec Transport mode, and explains the packet structure differences along with the advantages and disadvantages of each mode.

GRE IPSec Tunnel Mode

With GRE IPSec tunnel mode, the whole GRE packet (which includes the original IP header packet), is encapsulated, encrypted and protected inside an IPSec packet.  GRE over IPSec Tunnel mode provides additional security because no part of the GRE tunnel is exposed, however, there is a significant overhead added to the packet. This additional overhead decreases the usable free space for our payload (Original IP packet), that means possibly more fragmentation will occur when transmitting data over a GRE IPSec Tunnel VPN.

IPSec Tunnel mode is the default configuration option for both GRE and non-GRE IPSec VPNs. When configuring the IPSec transform set, no other configuration commands are required to enable tunnel mode:

Calculating GRE IPSec Tunnel Mode Overhead

John Korakis, another respected Firewall.cx member, takes a look at one of Cisco Press's popular releases: Cisco LAN Switching (CCIE Professional Development Series). Read what John has to say about this exciting title and how it can help engineers, administrators and IT Managers understand more about their LAN switching environments.

"If “Routing TCP/IP Vol 1 & 2” by Jeff Doyle and Jennifer Carroll is considered the bible of Routing, this book should definitely be considered the bible of LAN Switching. The authors cover a wide spectrum of technologies in great detail, combining technical with easy to read writing...."

IPSec’s protocol objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality.

As outlined in our IPSec protocol article, Encapsulating Security Payload (ESP) and Authentication Header (AH) are the two IPSec security protocols used to provide these security services.  Analysing  the ESP and AH protocols is out of this article’s scope, however you can turn to our IPSec article where you’ll find an in-depth analysis and packet diagrams to help make the concept clear.

Understanding IPSec Modes –Tunnel Mode & Transport Mode

IPSec can be configured to operate in two different modes, Tunnel and Transport mode. Use of each mode depends on the requirements and implementation of IPSec.

IPSec Tunnel Mode

IPSec tunnel mode is the default mode. With tunnel mode, the entire original IP packet is protected by IPSec. This means IPSec wraps the original packet, encrypts it, adds a new IP header and sends it to the other side of the VPN tunnel (IPSec peer).

Tunnel mode is most commonly used between gateways (Cisco routers or ASA firewalls), or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it.

In tunnel mode, an IPSec header (AH or ESP header) is inserted between the IP header and the upper layer protocol. Between AH and ESP,  ESP is most commonly used in IPSec VPN Tunnel configuration.

The packet diagram below illustrates IPSec Tunnel mode with ESP header:

 ESP is identified in the New IP header with an IP protocol ID of 50.

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that allows the encapsulation of a wide variety of network layer protocols inside point-to-point links.

A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and packets are sent through the GRE tunnel.

It is important to note that packets travelling inside a GRE tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If data protection is required, IPSec must be configured to provide data confidentiality – this is when a GRE tunnel is transformed into a secure VPN GRE tunnel.

The diagram below shows the encapsulation procedure of a simple - unprotected GRE packet as it traversers the router and enters the tunnel interface:

While many might think a GRE IPSec tunnel between two routers is similar to a site to site IPSec VPN (crypto), it is not. A major difference is that GRE tunnels allow multicast packets to traverse the tunnel whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN.

This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between endpoints. We explain all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.

Creating a Cisco GRE Tunnel

GRE tunnel uses a ‘tunnel’ interface – a logical interface configured on the router with an IP address where packets are encapsulated and decapsulated as they enter or exit the GRE tunnel.

First step is to create our tunnel interface on R1:

All Tunnel interfaces of participating routers must always be configured with an IP address that is not used anywhere else in the network. Each Tunnel interface is assigned an IP address within the same network as the other Tunnel interfaces.

In our example, both Tunnel interfaces are part of the 172.16.0.0/24 network.

Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.

Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public network and encrypted using a number of advanced encryption algorithms to provide confidentiality of the data transmitted between the two sites.

This article will show how to setup and configure two Cisco routers to create a permanent secure site-to-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol. 

ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  

Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.  IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.

IPSec VPN Requirements

To help make this an easy-to-follow exercise, we have split it into two steps that are required to get the Site-to-Site IPSec VPN Tunnel to work.

These steps are:

(1)  Configure ISAKMP (ISAKMP Phase 1)

(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)

Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the Internet and have a static IP Address assigned by their ISP as shown on the diagram:

Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to securely connect both LAN networks and allow full communication between them, without any restrictions.

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on the Site 1 router (R1).

First step is to configure an ISAKMP Phase 1 policy:

The above commands define the following (in listed order):

• Vendor Name
• Vendor ID
• Serial Number
• Security Code
• CRC

How To Force Your Cisco Switch to Use 3rd Party SFPs

Despite the error displayed, which leaves no hope for a solution, keep smiling as you're about to be given one.

There are two undocumented commands which can be used to force the Cisco Catalyst switch to enable the GBIC port and use the 3rd party SFP:

When entering the service unsupported-transceiver command, the switch will automatically throw a warning message as a last hope to prevent the usage of a 3rd party SFP.

The no errdisable detect cause gbic-invalid command will help ensure the GBIC port is not disabled when inserting an invalid GIBC.

Since the service unsupported-transceiver  is undocumented, if you try searching for the command with the usual method (?), you won't find it:

In today’s complex network environments securing your network routers can be a daunting task, especially when there are so many CLI commands and parameters with different security implications for your Cisco router device.

Thankfully, since Cisco IOS version 12.3 and later, Cisco provides an easy way for administrators to lock down their Cisco router without entering complex commands and parameters.  This feature was smartly introduced to help remove the complexity of the task and ensure the lock-down is performed according to Cisco’s best security practices.

The Cisco AutoSecure feature is available to all IOS version 12.3 and above and supported on all hardware platforms, including all newer Cisco 870, 880, 1800, 1900, 2800, 2900, 3800 and 3900 series routers.

To maximize flexibility the Cisco AutoSecure command supports two different modes depending on your needs and flexibility required:

AutoSecure Interactive Mode: This mode prompts the user with options to enable/disable services and other security features supported by the IOS version the router is running.

AutoSecure Non-Interactive Mode:  Automatically executes the Cisco AutoSecure command using the recommended Cisco default settings (Cisco’s best security practices).

The Cisco AutoSecure Interactive mode provides greater control over security-related features than the non-interactive mode. However, when an administrator needs to quickly secure a router without much human intervention, the non-interactive mode is appropriate.

We’ll examine the practical difference between the two commands soon. For now, let’s take a look at the functions Cisco AutoSecure performs:

1. Disables the following Global Services:

• Finger
• PAD
• Small Servers
• Bootp
• HTTP service
• Identification Service
• CDP
• NTP
• Source Routing

2. Enables the following Global Services:

• Password-encryption service
• Tuning of scheduler interval/allocation
• TCP synwait-time
• TCP-keepalives-in and tcp-kepalives-out
• SPD configuration
• No ip unreachables for null 0

3. Disables the following services per interface:

When it comes to connecting multiple analog phones to VoIP systems like Cisco’s Unified Communication Manager Express (CallManager Express) or UC500 series (Includes UC520, UC540, UC560), the first thing that usually comes to mind is the expensive ATA 186/188 or newer ATA 187 devices (double the price of the older 186/188) that provide only two FXS analog ports per device.

While purchasing one or two ATA devices might be acceptable for up to two or four analog phones, this quickly becomes a very expensive practice for any additional FXS ports. Thankfully, there is a cheaper solution – the Cisco Linksys SPA8000.

The Cisco SPA8000 is an 8-port IP Telephony Gateway that allows connections for up to eight analog telephones (provides 8 FXS ports) to an IP-based data network. What many engineers are not aware of is that the SPA8000 can also be configured to connect to Cisco's CallManager Express or Cisco UC500 series IP Telephony system, decreasing dramatically the cost per FXS analog port of your VoIP network.

This article examines the necessary steps and configuration required to successfully connect a SPA8000 to a CallManager Express system.  The commands covered are identical to CallManager Express and all UC 500 series IP PBX systems (520, 540 & 560).

The diagram above shows the physical connection of the solution. The SPA8000, just like any VoIP device, is configured and connected to a network switch and assigned to VLAN2, the Voice VLAN in our example. By doing so, the SPA8000 is able to communicate with CallManager Express using the SIP Protocol as shown below.  On the back of the SPA8000, we've connected simple analog phones to FXS ports provided. These phones can be placed in areas where there is no need for the more expensive Cisco IP Phones, usually public areas, production environments etc.  Note that these analog phone devices can also be wireless analog phones.