GRE over IPsec

Point-to-Point Generic Routing Encapsulation over IP Security

Point-to-Point Generic Routing Encapsulation over IP Security

Generic Routing Encapsulation (GRE) is a widely used encapsulation protocol in computer networking. It allows the transmission of diverse network protocols over an IP network infrastructure. In this blog post, we'll delve into the details of the GRE and its significance in modern networking.

GRE acts as a tunneling protocol, encapsulating packets from one network protocol within another. By creating a virtual point-to-point link, it facilitates the transmission of data across different network domains. This enables the interconnection of disparate networks, making GRE a crucial tool for securely building virtual private networks (VPNs) and connecting remote sites.

P2P GRE is a tunneling protocol that allows the encapsulation of various network layer protocols within IP packets. It provides a secure and reliable method of transmitting data between two points in a network. By encapsulating packets in IP headers, P2P GRE ensures data integrity and confidentiality.

IP Security (IPsec) plays a crucial role in enhancing the security of P2P GRE tunnels. By leveraging cryptographic algorithms, IPsec provides authentication, integrity, and confidentiality of data transmitted over the network. It establishes a secure channel between two endpoints, ensuring that data remains protected from unauthorized access and tampering.

Enhanced Network Security: P2P GRE over IP Security offers a robust security solution for organizations by providing secure communication channels across public and private networks. It allows for the establishment of secure connections between geographically dispersed locations, ensuring the confidentiality of sensitive data.

Improved Network Performance: P2P GRE over IP Security optimizes network performance by encapsulating and routing packets efficiently. It enables the transmission of data across different network topologies, reducing network congestion and enhancing overall network efficiency.

Seamless Integration with Existing Infrastructures: One of the key advantages of P2P GRE over IP Security is its compatibility with existing network infrastructures. It can be seamlessly integrated into existing networks without the need for significant architectural changes, making it a cost-effective solution for organizations.

Security Measures: Implementing P2P GRE over IP Security requires careful consideration of security measures. Organizations should ensure that strong encryption algorithms are utilized, proper key management practices are in place, and regular security audits are conducted to maintain the integrity of the network.

Scalability and Performance Optimization: To ensure optimal performance, network administrators should carefully plan and configure the P2P GRE tunnels. Factors such as bandwidth allocation, traffic prioritization, and Quality of Service (QoS) settings should be taken into account to guarantee the efficient operation of the network.

Highlights: Point-to-Point Generic Routing Encapsulation over IP Security

Generic Tunnelling – P2P GRE & IPSec

– P2P GRE is a tunneling protocol that allows the encapsulation of different network protocols within an IP network. It provides a secure and efficient mechanism for transmitting data between two network endpoints. By encapsulating packets, P2P GRE ensures that information is protected from external threats and remains intact during transmission.

– IPsec, on the other hand, is a suite of protocols that provides security services at the IP layer. It offers authentication, confidentiality, and integrity to IP packets, ensuring that data remains secure even when traversing untrusted networks. IPsec can be combined with P2P GRE to create a robust and secure communication channel.

– The combination of P2P GRE and IPsec brings several benefits to network administrators and organizations. Firstly, it enables secure communication between geographically dispersed networks, allowing for seamless connectivity. Additionally, P2P GRE over IPsec provides strong encryption, ensuring the confidentiality of sensitive data. It also allows for the creation of virtual private networks (VPNs), offering a secure and private network environment.

– P2P GRE over IPsec finds applications in various scenarios. One common use case is connecting branch offices of an organization securely. By establishing a P2P GRE over IPsec tunnel between different locations, organizations can create a secure network environment for their remote sites. Another use case is securely connecting cloud resources to on-premises infrastructure, enabling secure and seamless integration.

**The Role of GRE**

A: In GRE, packets are wrapped within other packets that use supported protocols, allowing the use of protocols not generally supported by a network. To understand this, consider the difference between a car and a ferry. On land, cars travel on roads, while ferries travel on water.

B: Usually, cars cannot travel on water but can be loaded onto ferries. In this analogy, terrain could be compared to a network that supports specific routing protocols and vehicles to data packets. Similarly, one type of vehicle (the car) is loaded onto a different kind of vehicle (the ferry) to cross terrain it could not otherwise.

GRE tunneling: how does it work?

GRE tunnels encapsulate packets within other packets. Each router represents the end of the tunnel. GRE packets are exchanged directly between routers. When routers are between forwarding packets, they use headers surrounding them rather than opening the encapsulated packets. Every packet of data sent over a network has the payload and the header. The payload contains the data being sent, while the headers contain information about the source and group of the packet. Each network protocol attaches a header to each packet.

Unlike load limits on automobile bridges, data packet sizes are limited by MTU and MSS. An MSS measurement only measures a packet’s payload, not its headers. Including the headers, the MTU measures the total size of a packet. Packets that exceed MTU are fragmented to fit through the network.

GRE configuration

GRE Operation

GRE is a layer three protocol, meaning it works at the IP level of the network. It enables a router to encapsulate packets of a particular protocol and send them to another router, where they are decapsulated and forwarded to their destination. This is useful for tunneling, where data must traverse multiple networks and different types of hardware.

GRE encapsulates data in a header containing information about the source, destination, and other routing information. The GRE header is then encapsulated in an IP header containing the source and destination IP addresses. When the packet reaches the destination router, the GRE header is stripped off, and the data is sent to its destination.

GRE over IPsec

**Understanding Multipoint GRE**

Multipoint GRE, or mGRE, is a tunneling protocol for encapsulating packets and transmitting them over an IP network. It enables virtual point-to-multipoint connections, allowing multiple endpoints to communicate simultaneously. By utilizing a single tunnel interface, mGRE simplifies network configurations and optimizes resource utilization.

One of Multipoint GRE’s standout features is its ability to transport multicast and broadcast traffic across multiple sites efficiently. It achieves this through a single tunnel interface, eliminating the need for dedicated point-to-point connections. This scalability and flexibility make mGRE an excellent choice for large-scale deployments and multicast applications.

Multipoint GRE & DMVPN:

DMVPN, as the name suggests, is a virtual private network technology that dynamically creates VPN connections between multiple sites without needing dedicated point-to-point links. It utilizes a hub-and-spoke architecture, with the hub as the central point for all communication. Using the Next Hop Resolution Protocol (NHRP), DMVPN provides a highly scalable and flexible solution for securely interconnecting sites.

Multipoint GRE, or mGRE, is a tunneling protocol my DMVPN uses to create point-to-multipoint connections. It allows multiple spokes to communicate directly with each other, bypassing the hub. By encapsulating packets within GRE headers, mGRE establishes virtual links between spokes, providing a flexible and efficient method of data transmission.

Google HA VPN

Understanding HA VPN

HA VPN is a highly scalable and redundant VPN solution provided by Google Cloud. It allows you to establish secure connections over the public internet while ensuring high availability and reliability. With HA VPN, you can connect your on-premises networks to Google Cloud, enabling secure data transfer and communication.

To begin configuring HA VPN, you must first set up a virtual private cloud (VPC) network in Google Cloud. This VPC network will serve as the backbone for your VPN connection. Next, you must create a VPN gateway and configure the necessary parameters, such as IP addresses, routing, and encryption settings. Google Cloud provides a user-friendly interface and comprehensive documentation to guide you through this process.

Once the HA VPN configuration is set up in Google Cloud, it’s time to establish connectivity with your on-premises networks. This involves configuring your on-premises VPN gateway or router to connect to the HA VPN gateway in Google Cloud. You must ensure that the IPsec VPN parameters, such as pre-shared keys and encryption algorithms, are correctly configured on both ends for a secure and reliable connection.

IPSec Security

Securing GRE:

IPsec, short for Internet Protocol Security, is a protocol suite that provides secure communication over IP networks. It operates at the network layer of the OSI model, offering confidentiality, integrity, and authentication services. By encrypting and authenticating IP packets, IPsec effectively protects sensitive data from unauthorized access and tampering.

Components of IPsec:

To fully comprehend IPsec, we must familiarize ourselves with its core components. These include the Authentication Header (AH), the Encapsulating Security Payload (ESP), Security Associations (SAs), and Key Management protocols. AH provides authentication and integrity, while ESP offers confidentiality and encryption. SAs establish the security parameters for secure communication, and Key Management protocols handle the exchange and management of cryptographic keys.

The adoption of IPsec brings forth a multitude of advantages for network security. First, it ensures data confidentiality by encrypting sensitive information, making it indecipherable to unauthorized individuals. Second, IPsec guarantees data integrity, as any modifications or tampering attempts would be detected. Additionally, IPsec provides authentication, verifying the identities of communicating parties, thus preventing impersonation or unauthorized access.

When IPsec and GRE are combined, they create a robust network security solution. IPsec ensures the confidentiality and integrity of data, while GRE enables the secure transmission of encapsulated non-IP traffic. This integration allows organizations to establish secure tunnels for transmitting sensitive information while extending their private networks securely.

Benefits of GRE over IPSEC:

Secure Data Transmission: By leveraging IPSEC’s encryption and authentication capabilities, GRE over IPSEC ensures the confidentiality and integrity of data transmitted over the network. This is particularly crucial when transmitting sensitive information, such as financial data or personal records.

Network Scalability: GRE over IPSEC allows organizations to create virtual private networks (VPNs) by establishing secure tunnels between remote sites. This enables seamless communication between geographically dispersed networks, enhancing collaboration and productivity.

Protocol Flexibility: GRE over IPSEC supports encapsulating various network protocols, including IPv4, IPv6, and multicast traffic. This flexibility enables the transmission of diverse data types, ensuring compatibility across different network environments.

The Role of VPNs

VPNs are deployed on an unprotected network or over the Internet to ensure data integrity, authentication, and encryption. Initially, VPNs were designed to reduce the cost of unnecessary leased lines. As a result, they now play a critical role in securing the internet and, in some cases, protecting personal information.

In addition to connecting to their corporate networks, individuals use VPNs to protect their privacy. Data integrity, authentication, and encryption through L2F, L2TP, GRE, or MPLS VPNs are impossible. However, IPsec can also benefit these protocols when combined with L2TP, GRE, and MPLS. These features make IPsec the preferred protocol for many organizations.

DMVPN over IPsec
Diagram: DMVPN over IPsec

GRE over IPsec

A GRE tunnel allows unicast, multicast, and broadcast traffic to be tunneled between routers and is often used to route traffic between different sites. A disadvantage of GRE tunneling is that it is clear text and offers no protection. Cisco IOS routers, however, allow us to encrypt the entire GRE tunnel, providing a safe and secure site-to-site tunnel.

RFC 2784 defines GRE (protocol 47), and RFC 2890 extends it. Using GRE, packets of any protocol (the payload packets) can be encapsulated over any other protocol (the delivery protocol) between two endpoints. Between the payload (data) and the delivery header, the GRE protocol adds its header (4 bytes plus options).

Tip:

GRE supports IPv4 and IPv6. If IPv4 or IPv6 endpoint addresses are defined, the outer IP header will be IPv4 or IPv6, respectively. In comparison to the original packet, GRE packets have the following overhead:

  • 4 bytes (+ GRE options) for the GRE header.
  • 20 bytes (+ IP options) for the outer IPv4 header (GRE over IPv4), or
  • 40 bytes (+ extension headers) for the outer IPv6 header (GRE over IPv6).

GRE over IPsec creates a new IP packet inside the network infrastructure device by encapsulating the original packets within GRE.

When GRE over IPsec is deployed in tunnel mode, the plaintext IPv4 or IPv6 packet is encapsulated into GRE. The tunnel source and destination IP addresses are then encapsulated in another IPv4 or IPv6 packet. An IPsec tunnel source and tunnel destination route the traffic to the destination with an additional outer IP header acting as a tunnel source and tunnel destination.

On the other hand, GRE over IPsec encapsulates plaintext IPv4 or IPv6 packets in GRE and then protects them with IPsec for confidentiality and integrity; the outer IP header with the source and destination addresses of the GRE tunnel enables packet routing.

IPsec site-to-site

An IPsec site-to-site VPN, also known as a gateway-to-gateway VPN, is a secure tunnel established between two or more remote networks over the internet. It enables organizations to connect geographically dispersed offices, data centers, or even cloud networks, creating a unified and secure network infrastructure. By leveraging IPsec, organizations can establish secure communication channels, ensuring confidentiality, integrity, and authentication of transmitted data.

GRE with IPsec

Advanced Topics

GETVPN:

– GetVPN, short for Group Encrypted Transport VPN, is a Cisco proprietary technology that provides secure site communication. It operates in the network layer and employs a key server to establish and distribute encryption keys to participating devices.

– This approach enables efficient and scalable deployment of secure VPNs across large networks. GetVPN offers robust security measures, including data confidentiality, integrity, and authentication, making it an excellent choice for organizations requiring high levels of security.

– When you run IPSec over a hub-and-spoke topology like DMVPN, the hub router has an IPSec SA with every spoke router. As a result, you are limited in the number of spoke routers you can use. Direct spoke-to-spoke traffic is supported in DMVPN, but when a spoke wants to send traffic to another spoke, it must first create an IPSec SA, which takes time.

Multicast traffic cannot be encapsulated with traditional IPSec unless first encapsulated with GRE.

GETVPN solves the scalability issue by using a single IPSec SA for all routers in a group. Multicast traffic is also supported without GRE.

Understanding IPv6 Tunneling

IPv6 tunneling is a mechanism that enables the encapsulation of IPv6 packets within IPv4 packets, allowing them to traverse an IPv4 network infrastructure. This allows for the coexistence and communication between IPv6-enabled devices over an IPv4 network. The encapsulated IPv6 packets are then decapsulated at the receiving end of the tunnel, restoring the original IPv6 packets.

Types of IPv6 Tunneling Techniques

There are several tunneling techniques used for IPv6 over IPv4 connectivity. Let’s explore a few prominent ones:

Manual IPv6 Tunneling: Manual IPv6 tunneling involves manually configuring tunnels on both ends. This method requires the knowledge of the source and destination IPv4 addresses and the tunneling protocol to be used. While it offers flexibility and control, manual configuration can be time-consuming and error-prone.

Automatic 6to4 Tunneling: Automatic 6to4 tunneling utilizes the 6to4 addressing scheme to assign IPv6 addresses to devices automatically. It allows IPv6 packets to be encapsulated within IPv4 packets, making them routable over an IPv4 network. This method simplifies the configuration process, but it relies on the availability of public IPv4 addresses.

Teredo Tunneling: Teredo tunneling is designed for IPv6 connectivity over IPv4 networks when the devices are located behind a NAT (Network Address Translation) device. It employs UDP encapsulation to transmit IPv6 packets over IPv4. Teredo tunneling can be helpful in scenarios where native IPv6 connectivity is unavailable.

Before you proceed, you may find the following posts helpful for pre-information:

  1. Dead Peer Detection
  2. IPsec Fault Tolerance
  3. Dynamic Workload Scaling 
  4. Cisco Switch Virtualization
  5. WAN Virtualization
  6. VPNOverview

Point-to-Point Generic Routing Encapsulation over IP Security

Guide on IPsec site to site

In this lesson, two Cisco IOS routers use IPSec in tunnel mode. This means the original IP packet will be encapsulated in a new IP packet and encrypted before sending it out of the network. For this demonstration, I will be using the following three routers.

R1 and R3 each have a loopback interface behind them with a subnet. We’ll configure the IPsec tunnel between these routers to encrypt traffic from 1.1.1.1/32 to 3.3.3.3/32. R2 is just a router in the middle, so R1 and R3 are not directly connected.

Notice with information 1 that we can’t ping the remote LAN. However, once the IPsec tunnel is up, we have reachability. Under the security associations, we have 4 packets encapsulated and encapsulated. However, I sent 5 pings. The first packet is lost to ARP.

ipsec tunnel
Diagram: IPsec Tunnel

IPsec relies on encryption and tunneling protocols to establish a secure connection between networks. The two primary components of IPsec are the IPsec tunnel mode and the IPsec transport mode. In tunnel mode, the entire IP packet is encapsulated within another IP packet, adding an extra layer of security. In contrast, the transport mode only encrypts the payload of the IP packet, leaving the original IP header intact.

To initiate a site-to-site VPN connection, the IPsec VPN gateway at each site performs a series of steps. These include negotiating the security parameters, authenticating the participating devices, and establishing a secure tunnel using encryption algorithms such as AES (Advanced Encryption Standard) or 3DES (Triple Data Encryption Standard). Once the tunnel is established, all data transmitted between the sites is encrypted, safeguarding it from unauthorized.

Back to basic with GRE tunnels

What is a GRE tunnel?

A GRE tunnel supplies connectivity to a wide variety of network layer protocols. GRE works by encapsulating and forwarding packets over an IP-based network. The authentic use of GRE tunnels provided a transport mechanism for non-routable legacy protocols such as DECnet and IPX. With GRE, we add header information to a packet when the router encapsulates it for transit on the GRE tunnel.

The new header information contains the remote endpoint IP address as the destination. The latest IP headers permit the packet to be routed between the two tunnel endpoints, and this is done without inspection of the packet’s payload.

After the packet reaches the remote endpoint, the GRE termination point, the GRE headers are removed, and the original packet is forwarded from the remote router. Both GRE and IPsec tunnels are used in solutions for SD WAN SASE and SD WAN Security. Both solutions abstract the complexity of configuring these technologies.

GRE Operation

GRE operates by encapsulating the original packet with a GRE header. This header contains information such as the source and destination IP addresses and additional fields for protocol identification and fragmentation support. Once the packet is encapsulated, it can be transmitted over an IP network, effectively hiding the underlying network details.

When a GRE packet reaches its destination, the receiving end decapsulates it, extracting the original payload. This process allows the recipient to receive the data as if it were sent directly over the underlying network protocol. GRE is a transparent transport mechanism, enabling seamless communication between disparate networks.

GRE Tunnel
Diagram: GRE tunnel example. Source is heficed

Guide on Point-to-Point GRE

Tunneling is putting packets into packets to transport them over a particular network. This is also known as encapsulation.

You might have two sites with IPv6 addresses on their LANs, but they only have IPv4 addresses when connected to the Internet. In normal circumstances, IPv6 packets would not be able to reach each other, but tunneling allows IPv6 packets to be routed on the Internet by converting IPv6 packets into IPv4 packets.

You might also want to run a routing protocol between your HQ and a branch site, such as RIP, OSPF, or EIGRP. By tunneling these protocols, we can exchange routing information between the HQ and branch routers.

When you configure a tunnel, you’re creating a point-to-point connection between two devices. We can accomplish this with GRE (Generic Routing Encapsulation). Let me show you a topology to demonstrate the GRE.

GRE configuration

In the image above, we have three routers connected. We have our headquarters router on the left side. On the right side, there is a “Branch” router. There is an Internet connection on both routers. An ISP router is located in the middle, on top. This topology can be used to simulate two routers connected to the Internet. A loopback interface represents the LAN on both the HQ and Branch routers.

EIGRP will be enabled on the loopback and tunnel interfaces. Through the tunnel interface, both routers establish an EIGRP neighbor adjacency. The next hop is listed as the tunnel interface in the routing table. We use GRE to tunnel our traffic, but it does not encrypt it like a VPN does. Our tunnel can be encrypted using IPSEC, one of the protocols.GRE without IPsec

Guide on Point-to-Point GRE with IPsec

A GRE tunnel allows unicast, multicast, and broadcast traffic to be tunneled between routers and is often used to send routing protocols between sites. GRE tunneling has the disadvantage of being clear text and unprotected. Cisco IOS routers, however, support IPsec encryption of the entire GRE tunnel, allowing a secure site-to-site tunnel. The following shows an encrypted GRE tunnel with IPsec.

We have three routers above. Each HQ and Branch router has a loopback interface representing its LAN connection. The ISP router connects both routers to “the Internet.” I have created a GRE tunnel between the HQ and Branch routers; all traffic between 172.16.1.0 /24 and 172.16.3.0 /24 will be encrypted with IPsec.

GRE with IPsec

For the IPsec side of things, I have configured an ISAKMP policy. In the example, I specify that I want 256-bit AES encryption and that we want a pre-shared key. We rely on Diffie-Hellman Group 5 for key exchange. The ISAKMP security association’s lifetime is 3600 seconds. The pre-shared key needs to be on both routers highlighted with a circle. Also, I created a transform-set called ‘TRANS’ that specifies we want ESP AES 256-bit and HMAC-SHA authentication.

Then, we create a crypto map that tells the router what traffic to encrypt and what transform set to use.

ipsec plus GRE

**How GRE and IPSec Work Together**

GRE and IPSec often work together to enhance network security. GRE provides the encapsulation mechanism, allowing the creation of secure tunnels between networks. IPSec, on the other hand, provides the necessary security measures, such as encrypting and authenticating the encapsulated packets. By combining both technologies’ strengths, organizations can establish secure and private connections between networks, ensuring data confidentiality and integrity.

**Benefits of GRE and IPSec**

The utilization of GRE and IPSec offers several benefits for network security. Firstly, GRE enables the transport of multiple protocols over IP networks, allowing organizations to leverage different network layer protocols without compatibility issues. Secondly, IPSec provides a robust security framework, protecting sensitive data from unauthorized access and tampering. GRE and IPSec enhance network security, enabling organizations to establish secure connections between geographically dispersed networks.

Topologies and routing protocol support

– Numerous technologies connect remote branch sites to HQ or central hub. P2P Generic Routing Encapsulation ( GRE network ) over IPsec is an alternative design to classic WAN technologies like ATM, Frame Relay, and Leased lines. GRE over IPsec is a standard deployment model that connects several remote branch sites to one or more central sites. Design topologies include the hub-and-spoke, partial mesh, and full mesh.

– Both partial and full-mesh topologies experience limitations in routing protocol support. A full mesh design is limited by the overhead required to support a design with a full mesh of tunnels. Following a complete mesh requirement, a popular design option would be to deploy DMVPN. Regarding the context of direct connectivity from branch to hub only, hub-and-spoke is by far the most common design.

Guide with DMVPN and GRE

The lab guide below shows a DMVPN network based on Generic Routing Encapsulation (GRE), which is the overlay. Specifically, we use GRE in point-to-point mode, which means deploying DMVPN Phase 1, a true VPN hub-and-spoke design, where all traffic from the spokes must go via the hub. With the command show dmvpn, we can see that two spokes are dynamically registered over the GRE tunnel; notice the “D” attribute.

The beauty of using DMPVN as a VPN technology is that the hub site does not need a specific spoke configuration as it uses GRE in multi-point mode. On the other hand, the spokes need to have a hub configuration with the command: IP nhrp nhs 192.168.100.11. IPsec encryption is optional with DMVPN. In the other command snippet, we are running IPsec encryption with the command: tunnel protection ipsec profile DMVPN_IPSEC_PROFILE.

DMVPN configuration
Diagram: DMVPN Configuration.

One of GRE’s primary use cases is creating VPNs. By encapsulating traffic within GRE packets, organizations can securely transmit data across public networks such as the Internet. This provides a cost-effective solution for connecting geographically dispersed sites without requiring dedicated leased lines.

Another use of the GRE is network virtualization. By leveraging GRE tunnels, virtual networks can be created isolated from the underlying physical infrastructure. This allows for more efficient resource utilization and improved network scalability.

**DMVPN (Dynamic Multipoint VPN)**

DMVPN is based on the principle of dynamic spoke-to-spoke tunneling, which allows for dynamic routing and scalability. It also allows for the creation of a dynamic mesh topology, allowing multiple paths between remote sites. This allows for increased redundancy and improved performance.

DMVPN also offers the ability to establish a secure tunnel over an untrusted network, such as the Internet. This is achieved with a series of DMVPN phases. DMVPN phase 3 offers better flexibility by using IPSec encryption and authentication, ensuring that all traffic sent over the tunnel is secure. This makes DMVPN an excellent choice for businesses connecting multiple sites over an unsecured network.

Dynamic Multipoint VPN
Diagram: Example with DMVPN. Source is Cisco

GRE Network: Head-end Architecture 

Single-tier and dual-tier

Head-end architectures include a single-tier head-end where the point-to-point GRE network and crypto functionality co-exist on the same device. Dual-tier designs are where the point-to-point GRE network and crypto functionality are not implemented on the same device. In dual-tier designs, the routing and GRE control planes are located on one device, while the IPsec control plane is housed on another.

what is generic routing encapsulation
Diagram: What is generic routing encapsulation?

Headend

Router

Crypto

Crypto IP

GRE  

GRE IP

Tunnel Protection

Single Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Optional 


Branch

Static

Static or Dynamic

p2p GRE static

Static

Optional 

Dual Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Not Valid


Branch

Static

Static or Dynamic

p2p GRE static

Static

Not Valid

“Tunnel protection” requires the same source and destination IP address for the GRE and crypto tunnels. Implementations of dual-tier separate these functions, resulting in the different IP addresses for the GRE and crypto tunnels. Tunnel protection is invalid with dual-tier mode.

GRE over IPsec

GRE (Generic Routing Encapsulation) is a tunneling protocol that encapsulates multiple protocols within IP packets, allowing the transmission of diverse network protocols over an IP network. On the other hand, IPSEC (IP Security) is a suite of protocols that provides secure communication over IP networks by encrypting and authenticating IP packets. Combining these two protocols, GRE over IPSEC offers a secure and flexible solution for transmitting network traffic over public networks.

Preliminary design considerations

Diverse multi-protocol traffic requirements force the use of a Generic Routing Encapsulation ( GRE ) envelope within the IPsec tunnel. The p2p GRE tunnel is encrypted inside the IPsec crypto tunnel. Native IPsec is not multi-protocol and lacks IP multicast or broadcast traffic support. As a result, proper propagation of routing protocol control packets cannot occur in a native IPsec tunnel.

However, OSPF design cases allow you to run OSPF network type non-broadcast and explicitly configure the remote OSPF neighbors, resulting in OSPF over the IPsec tunnel without GRE. With a GRE over IPsec design, all traffic between hub and branch sites is first encapsulated in the p2p GRE packet before encryption.

GRE over IPsec
Diagram: GRE over IPSec.

**GRE over IPSec Key Points**

Redundancy:

Redundant designs are implemented with the branch having two or more tunnels to the campus head. The head-end routers can be geographically separated or co-located. Routing protocols are used with redundant tunnels, providing high availability with dynamic path selection.

The head-end router can propagate a summary route ( 10.0.0.0/8 ) or a default route ( 0.0.0.0/0 ) to the branch sites, and a preferred routing metric will be used for the primary path. If OSPF is RP, the head-end selection is based on OSPF costs.

Recursive Routing:

Each branch must add a static route to their respective ISP IP addresses for each head-end. The static avoids recursive routing through the p2p GRE tunnel. Recursive routing occurs when the route to the GRE tunnel source outside the IP address of the opposing router is learned via a route with a next-hop of the inside IP address of the opposing p2p GRE tunnel.

Recursive routing causes the tunnel to flap and the p2p GRE packets to route into their p2p GRE tunnel. To overcome recursive routing, my best practice is to ensure that the outside tunnel is routed directly to ISP instead of inside the p2p GRE tunnel.

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

Recursive routing and outbound interface selection pose significant challenges in tunnel or overlay networks. Therefore, routing protocols should be used with utmost caution over network tunnels. A router can encounter problems if it attempts to reach the remote router’s encapsulating interface (transport IP address) via the tunnel. Typically, this issue occurs when the transport network is advertised using the same routing protocol as the overlay network.

Routers learn the destination IP address for tunnel interfaces through recursive routing. First, the IP address of the tunnel’s destination is removed from the routing table, making it unreachable.

Split tunneling

If the head-end advertises a summary route to the branch, split tunneling is enabled on all packets not destined for the summary. Any packets not destined for the summary are split-tunneled to the Internet. For example, split tunneling is not used for the branch sites in a design where the head-end router advertises a default route ( 0.0.0.0/0 ) through the p2p GRE tunnel.

A key point: Additional information on Split tunneling.

Split tunneling is a networking concept that allows users to selectively route traffic from their local device to a local or remote network. It gives users secure access to corporate networks and other resources from public or untrusted networks. Split tunneling can also be used to reduce network congestion. For example, if a user is on a public network and needs to access a resource on a remote network, the user can set up a split tunnel to send only the traffic that needs to go over the remote network. This reduces the traffic on the public network, allowing it to perform more efficiently.

Control plane

Routing protocol HELLO packets initiated from the branch office force the tunnel to establish—routing protocol control plane packets to maintain and keep the tunnel up. HELLO packets provide a function similar to GRE keepaways. The HELLO routing protocol operates in layer 3, and GRE is maintained in layer 2.

 Branch router considerations

The branch router can have p2p GRE over IPSEC with a static or dynamic public address. The GRE and crypto tunnels are sourced from a static address with a static public IP address. With dynamic address allocation, the GRE is sourced from a loopback address privately assigned (non-routable), and the crypto tunnel is sourced from a dynamically assigned public IP address.

Closing Points on GRE with IPsec

GRE allows for the encapsulation of packets from various network protocols, providing a versatile solution for creating point-to-point links. Meanwhile, IPsec ensures these connections are secure, encrypting the data to protect it from interception and tampering. In this blog post, we’ll explore how to implement a point-to-point GRE tunnel secured by IPsec on Google Cloud, helping you create a robust and secure network architecture.

The first step in establishing a secure point-to-point link is setting up GRE tunnels. GRE is a tunneling protocol that encapsulates a wide variety of network layer protocols inside virtual point-to-point links. When configuring GRE on Google Cloud, you’ll need to create a Virtual Private Cloud (VPC) network, assign static IP addresses to your virtual machines, and configure the GRE tunnels on both ends. This setup allows for seamless data transfer across your network, regardless of underlying network infrastructure.

Once the GRE tunnel is established, the next step is to secure it using IPsec. IPsec provides encryption and authentication services for your data, ensuring that only authorized users can access it and that the data remains unaltered during transmission. On Google Cloud, you can configure IPsec by setting up Cloud VPN or using third-party tools to establish a secure IPsec tunnel. This involves generating and exchanging security keys, configuring security policies, and ensuring that your firewall rules allow IPsec traffic. With IPsec, your GRE tunnel becomes a secure conduit for your data, protected from potential threats.

One of the key advantages of using Google Cloud for your GRE and IPsec setup is the seamless integration with other Google Cloud services. Whether you’re connecting different regions, linking on-premises networks with cloud resources, or setting up a hybrid cloud environment, Google Cloud’s suite of services can enhance your network’s functionality and performance. Services like Google Cloud Interconnect, Cloud DNS, and Cloud Load Balancing can be incorporated into your architecture to optimize data flow, manage traffic, and ensure high availability.

Summary: Point-to-Point Generic Routing Encapsulation over IP Security

Point-to-Point Generic Routing Encapsulation (P2P GRE) over IP Security (IPsec) stands out as a robust and versatile solution in the vast realm of networking protocols and security measures. This blog post will delve into the intricacies of P2P GRE over IPsec, exploring its features, benefits, and real-world applications.

Understanding P2P GRE

P2P GRE is a tunneling protocol that encapsulates various network layer protocols over IP networks. It establishes direct communication paths between multiple endpoints, creating virtual point-to-point connections. By encapsulating data packets within IP packets, P2P GRE enables secure transmission across public or untrusted networks.

Exploring IPsec

IPsec serves as the foundation for securing network communications. It provides authentication, confidentiality, and integrity to protect data transmitted over IP networks. By combining IPsec with P2P GRE, organizations can achieve enhanced security and privacy for their data transmissions.

Benefits of P2P GRE over IPsec

– Scalability: P2P GRE supports the creation of multiple tunnels, enabling flexible and scalable network architectures.

– Versatility: The protocol is platform-independent and compatible with various operating systems and network devices.

– Efficiency: P2P GRE efficiently handles encapsulation and decapsulation processes, minimizing overhead and ensuring optimal performance.

– Security: Integrating IPsec with P2P GRE ensures end-to-end encryption, authentication, and data integrity, safeguarding sensitive information.

Real-World Applications

P2P GRE over IPsec finds extensive use in several scenarios:

– Secure Site-to-Site Connectivity: Organizations can establish secure connections between geographically dispersed sites, ensuring private and encrypted communication channels.

– Virtual Private Networks (VPNs): P2P GRE over IPsec forms the backbone of secure VPNs, enabling remote workers to access corporate resources securely.

– Cloud Connectivity: P2P GRE over IPsec facilitates secure connections between on-premises networks and cloud environments, ensuring data confidentiality and integrity.

Conclusion:

P2P GRE over IPsec is a powerful combination that offers secure and efficient communication across networks. Its versatility, scalability, and robust security features make it an ideal choice for organizations seeking to protect their data and establish reliable connections. By harnessing the power of P2P GRE over IPsec, businesses can enhance their network infrastructure and achieve higher data security.

ip routing

Advances of IP routing and Cloud

 

ip routing

 

With the introduction and hype around Software Defined Networking ( SDN ) and Cloud Computing, one would assume that there has been little or no work with the advances in IP routing. You could say that the cloud has clouded the mind of the market. Regardless of the hype around this transformation, routing is still very much alive and makes up a vital part of the main internet statistics you can read. Packets still need to get to their destinations.

 

Advanced in IP Routing

The Internet Engineering Task Force (IETF) develops and promotes voluntary internet standards, particularly those that comprise the Internet Protocol Suite (TCP/IP). The IETF shapes what comes next, and this is where all the routing takes place. It focuses on anything between the physical layer and the application layer. It doesn’t focus on the application itself, but on the technologies used to transport it, for example, HTTP.

In the IETF, no one is in charge, anyone can contribute, and everyone can benefit. As you can see from the chart below, that routing ( RTG ) has over 250 active drafts and is the most popular working group within the IETF.

 

 

IP routinng
Diagram: IETF Work Distribution.

 

The routing area is responsible for ensuring the continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols and developing new protocols, extensions, and bug fixes promptly

The following table illustrates the subgroups of the RTG working group:

Bidirectional Forwarding Detection (BFD) Open Shortest Path First IGP (OSPF)
Forwarding and Control Element Separation (forces) Routing Over Low power and Lossy networks (roll)
Interface to the Routing System (i2rs) Routing Area Working Group (RTGW)
Inter-Domain Routing (IDR) Secure Inter-Domain Routing (SCIDR)
IS-IS for IP Internets (isis) Source Packet Routing in Networking (spring)
Keying and Authentication for Routing Protocols (Karp)
Mobile Ad-hoc Networks (manet)

The chart below displays the number of drafts per subgroup of the routing area. There has been a big increase in the subgroup “roll,” which is second to BGP. “Roll” relates to “Routing Over Low power and Lossy networks” and is driven by the Internet of Everything and Machine-to-Machine communication.

 

IP ROUTING
Diagram: RTG Ongoing Work.

 

OSPF Enhancements

OSPF is a link-state protocol that uses a common database to determine the shortest path to any destination.

Two main areas of interest in the Open Shortest Path First IGP (OSPF) subgroups are OSPFv3 LSA Extendibility and Remote Loop-Free Alternatives ( LFAs ). One benefit IS-IS has over OSPF is its ability to easily introduce new features with the inclusion of Type Length Values ( TLVs ) and sub-TLVs. The IETF draft-IETF-OSPF-ospfv3-lsa-extend extends the LSA format by allowing the optional inclusion of TLVs, making OSPF more flexible and extensible. For example, OSPFv3 uses a new TLV to support intra-area Traffic Engineering ( TE ), while OSPFv2 uses an opaque LSA.

 

TLV for OSPFv3
Diagram: TLV for OSPFv3.

 

Another shortcoming of OSPF is that it does not install a backup route in the routing table by default. Having a pre-installed backup up path greatly improves convergence time. With pre-calculated backup routes already installed in the routing table, the router process does not need to go through the convergence process’s LSA propagation and SPF calculation steps.

 

Loop-free alternatives (LFA)

Loop-Free Alternatives ( LFA ), known as Feasible Successors in EIGRP, are local router decisions to pre-install a backup path.
In the diagram below:

-Router A has a primary ( A-C) and secondary ( A-B-C) path to 10.1.1.0/24
-Link State allows Router A to know the entire topology
-Router A should know that Router B is an alternative path. Router B is a Loop-Free Alternate for destination 10.1.1.0/24

OSPF LFA
Diagram: OSPF LFA.

 

This is not done with any tunneling, and the backup route needs to exist for it to be used by the RIB. If the second path doesn’t exist in the first place, the OSPF process cannot install a Loop-Free Alternative. The LFA process does not create backup routes if they don’t already exist. An LFA is simply an alternative loop-free route calculated at any network router.

A drawback of LFA is that it cannot work in all topologies. This is most notable in RING topologies. The answer is to tunnel and to get the traffic past the point where it will loop. This effectively makes the RING topology a MESH topology. For example, the diagram below recognizes that we must tunnel traffic from A to C. The tunnel type doesn’t matter – it could be a GRE tunnel, an MPLS tunnel, an IP-in-IP tunnel, or just about any other encapsulation.

 

In this network:

-Router A’s best path through E
-Routers C’s best path is through D
-Router A must forward traffic directly to C to prevent packets from looping back.

Remote LFA
Diagram: Remote LFA.

 

In the preceding example, we will look at “Remote LFA,” which leverages an MPLS network and Label Distribution Protocol ( LDP ) for label distribution. If you use Traffic Engineering ( TE ), it’s called “TE Fast ReRoute” and not “Remote LFA.” There is also a hybrid model combining Remote LFA and TE Fast ReRoute, and is used only when the above cannot work efficiently due to a complex topology or corner case scenario.

Remote LFAs extend the LFA space to “tunneled neighbors”.

– Router A runs a constrained SPF and finds C is a valid LFA

– Since C is not directly connected, Router A must tunnel to C

a) Router A uses LDP to configure an MPLS path to C

b) Installs this alternate path as an LFA in the CEF table

– If the A->E link fails.

a) Router A begins forwarding traffic along the LDP path

The total time for convergence usually takes 10ms.

Remote LFA has some topology constraints. For example, they cannot be calculated across a flooding domain boundary, i.e., an ABR in OSPF or L1/L2 boundary is IS-IS. However, they work in about 80% of all possible topologies and 90% of production topologies.

 

BGP Enhancements

BGP is a scalable distance vector protocol that runs on top of TCP. It uses a path algorithm to determine the best path to install in the IP routing table and for IP forwarding.

 

Recap BGP route advertisement:

  • RR client can send to a RR client.
  • RR client can send to a non RR client.
  • A non-RR client cannot send to a non-RR client.

One drawback to the default BGP behavior is that it only advertises the best route. When a BGP Route Reflector receives multiple paths to the same destination, it will advertise only one of those routes to its neighbors.

This can limit the visibility in the network and affect the best path selection used for hot potato routing when you want traffic to leave your AS as quickly as possible. In addition, all paths to exit an AS are not advertised to all peers, basically hiding ( not advertising ) some paths to exit the network.

The diagram below displays default BGP behavior; the RR receives two routes from PE2 and PE3 about destination Z; due to the BGP best path mechanism, it only advertises one of those paths to PE1. 

Route Reflector - Default
Diagram: Route Reflector – Default.

 

In certain designs, you could advertise the destination CE with different Route Distinguishers (RDs), creating two instances for the same destination prefix. This would allow the RR to send two paths to PE.

 

Diverse BGP path distribution

Another new feature is diverse BGP Path distribution, where you can create a shadow BGP session to the RR. It is easy to deploy, and the diverse iBGP session will announce the 2nd best path. Shadow BGP sessions are especially useful in virtualized deployments, where you can create another BGP session to a VM acting as a Route-Reflector. The VM can then be scaled out in a virtualized environment creating numerous BGP sessions. You are allowing the advertisements of multiple paths for each destination prefix.

Route Reflector - Shadow Sessions
Diagram: Route Reflector – Shadow Sessions.

 

BGP Add-path 

A special extension to BGP known as “Add Paths” allows BGP speakers to propagate and accept multiple paths for the same prefix. The BGP Add-Path feature will signal diverse paths, so you don’t need to create shadow BGP sessions. There is a requirement that all Add-Path receiver BGP routers must support the Add-Path capability.

There are two flavors of the Add-Path capability, Add-n-path, and Add-all-path. The “Add-n-path” will add 2 or 3 paths depending on the IOS version. With “Add-all-path,” the route reflector will do the primary best path computation (only on the first path) and then send all paths to the BR/PE. This is useful for large ECMP load balancing, where you need multiple existing paths for hot potato routing.

BGP Add Path
Diagram: BGP Add Path

 

Source packet routing

Another interesting draft the IETF is working on is Source Packet Routing ( spring ). Source Packet Routing is the ability of a node to specify a forwarding path. As the packet arrives in the network, the edge device looks at the application, determines what it needs, and predicts its path throughout the network. Segment routing leverages the MPLS data plane, i.e., push, swap, and pop controls, without needing LDP or RSVP-TE. This avoids millions of labels in the LDP database or TE LSPs in the networks.

 

Application Controls - Network DeliversDiagram: Application Controls – Network Delivers 

The complexity and state are now isolated to the network’s edges, and the middle nodes are only swapping labels. The source routing is based on the notion of a 32-bit segment that can represent any instructions, such as service, context, or IGP-based forwarding construct. This results in an ordered chain of topological and service instructions where the ingress node pushes the segment list on the packet.

 

Prefix Hijacking in BGP

BGP hijacking revolves around locating an ISP that is not filtering advertisements, or its misconfiguration makes it susceptible to a man-in-the-middle attack. Once located, an attacker can advertise any prefix they want, causing some or all traffic to be diverted from the real source towards the attacker.

In February 2008, a large portion of YouTube’s address space was redirected to Pakistan when the Pakistan Telecommunication Authority ( PTA ) decided to restrict access to YouTube.com inside the country but accidentally blackholed the route in the global BGP table.

These events and others have led the Secure-Inter Domain Routing Group ( SIDR ) to address the following two vulnerabilities in BGP:

-Is the AS authorized to originate an IP prefix?

-Is the AS-Path represented in the route the same as the path through which the NLRI traveled?

This lockdown of BGP has three solution components:

 

RPKI Infrastructure Offline repository of verifiable secure objects based on public-key cryptography
Follows resources (IPv4/v6 + ASN) allocation hierarchy to provide “right of use”
BGP Secure Origin AS You only validate the Origin AS of a BGP UPDATE
Solves most frequent incidents (*)
No changes to BGP nor the router’s hardware impact
Standardization is almost finished and running code
BGP PATH Validation BGPSEC proposal under development at IETF
Requires forward signing AS-PATH attribute
Changes in BGP and possible routers

The roll-out and implementation should be gradual and create islands of trust worldwide. These islands of trust will eventually interconnect together, making BGP more secure.

The table below displays the RPKI Deployment State;

RIR Total Valid Invalid Unknown Accuracy RPKI Adoption Rate
AFRINIC 100% .44% .42% 99.14% 51.49% .86%
APNIC 100% .22% .24% 99.5% 48.32% .46%
ARIN 100% .4% .14% 99.46% 74.65% .54%
LACNIC 100% 17.84% 2.01% 80.15% 89.87% 19.85%
RIPE NCC 100% 6.7% 0.59% 92.71% 91.92% 7.29%

Cloud Enhancements – The Intercloud

Today’s clouds have crossed well beyond the initial hype, and applications are now offered as on-demand services ( anything-as-a-service [XaaS] ). These services are making significant cost savings, and the cloud transition is shaping up to be as powerful as the previous one – the Internet. The Intercloud and the Internet of Things are the two new big clouds of the future.

Currently, the cloud market is driven by two spaces – the public cloud ( off-premise ) and the private cloud (on-premise). The intercloud takes the concept of cloud much further and attempts to connect multiple public clouds. A single application that could integrate services and workloads from ten or more clouds would create opportunities and potentially alter the cloud market landscape significantly. Hence, it is important to know and understand the need for cloud migration and its related problems.

We are already beginning to see signs of this in the current market. Various applications, such as Spotify and Google Maps, authenticate unregistered users with their Facebook credentials. Another use case is a cloud IaaS provider could divert incoming workload to another provider if it doesn’t have the resources to serve the incoming requests, essentially cloud bursting from provider to provider. It would also make economic sense to move workload and services between cloud providers based on cooling costs ( follow the moon ). Or maybe dynamically move workloads between providers, so they are closest to the active user base ( follow the sun )

The following diagram displays a Dynamic Workload Migration between two Cloud companies.

 

Intercloud
Diagram: Intercloud.

 

A: Cloud 1 finds Cloud 2 -Naming, Presence
B: Cloud 1 Trusts Cloud 2 -Certificates, Trustsec
C: Both Cloud 1 and 2 negotiate -Security, Policy
D: Cloud 1 sets up Cloud 2 -Placement, Deployment
E: Cloud 1 sends to Cloud 2 -VM runs in cloud-Addressing, configurations

The concept of Intercloud was difficult to achieve with the previous version of vSphere based on the restriction of latency for VMotion to operate efficiently. Now vSphere v6 can tolerate 100 msec of RTT.

InterCloud is still a conceptual framework, and the following questions must be addressed before it can be moved from concept to production.

1) Intercloud security

2) Intercloud SLA management

3) Interoperability across cloud providers.

 

Cisco’s One Platform Kit (onePK)

The One Platform Kit is Cisco’s answer to Software Defined Networking. It aims to provide simplicity and agility to a programmatic network. It’s a set of APIs driven by programming languages, such as C and Java, that are used to program the network. We currently have existing ways to program the network with EEM applets but lack an automation tool that can program multiple devices simultaneously. It’s the same with Performance Routing ( PfR ). PfR can program and traffic engineer the network by remotely changing metrics, but the decisions are still local and not controller-based.

 

Traffic engineering

One useful element of Cisco’s One Platform Kit is its ability to perform “Off box” traffic engineering, i.e., the computation is made outside the local routing device. It allows you to create route paths throughout the network without relying on default routing protocol behavior. For example, the cost is the default metric for route selection for equal-length routes in OSPF. This cannot be changed, which makes the routing decisions very static. In addition, Cisco’s One Platform Kit (onePK) allows you to calculate routes using different variables you set, giving you complete path control.

 

ip routing