GRE tunnelGRE Tunnel Overview

Generic Routing Encapsulation (GRE) can provide a private, secure path for transporting packets through an otherwise public network. It does this by encapsulating the data packets and redirecting them to a device that de-encapsulates them and routes them to their final destination. This allows the source and destination switches to operate as if they have a virtual point-to-point connection. The beauty of it is that it will encapsulate many different types of traffic and de-encapsulate it on the receiving end.

Basically, any traffic sent to the tunnel interface gets “stuffed” into a envelope and sent to the remote gateway, removed from the envelope, and forwarded normally. The network that the traffic is being routed across only sees GRE and not the individual IP header, and a GRE tunnel can be used with or without IPsec for encryption. This is great when you want to transport data over an IP infrastructure but not expose your addressing and routing structure. For example, if you’re building a VPN across a public IP infrastructure (say, to connect production to your DR site, for example). It’s also multi-protocol, so you can run IPv4 and IPv6 across the same GRE tunnel at the same time.

One of the biggest considerations when implementing a GRE tunnel between two once-independent environments is the pre-existing network addresses. Overlapping IP ranges may cause conflictions due to the emulated direct connection. So, preplanning and staging your networks is incredibly important before you begin to implement GRE tunneling.

Mostly we use GRE tunnels to help get routing protocols such as OSPF/EIGRP/RIP to share information with other devices across a VPN tunnel, but it’s also is a wonderful troubleshooting option, like for when an MPLS may be blocking traffic. I’ve also used a GRE tunnel to tunnel all multicast traffic across an MPLS network that does not support multicast. When I did this, the MPLS only saw GRE packets and the multicast streams worked great. Additionally, IPsec VPNs using GRE tunnels are great failover plans for direct MPLS connections (but we won’t go into that today).

In this post I will demonstrate how to create a GRE tunnel between two FortiGate firewalls (without going into adding IPsec). Traffic will then be encapsulated from the source and de-encapsulated and forwarded normally on the remote endpoint. It’s important to note that most of the GRE configuration within the FortiGate is command line interface only and can’t really be configured in the GUI.

Steps to Create a GRE Tunnel within FortiGate

  • Create system GRE tunnel and assign local and remote gateways (WAN IPs)
  • Modify system interface GRE settings and assign local/remote tunnel IPs (Tunnel IPs)
  • Create firewall policies to allow traffic
  • Create routes to remote side of the tunnel and select GRE tunnel as destination interface
  • Test

Creating the GRE Tunnel

The process is relatively straightforward and simple. First, we need to create our GRE tunnel. The two sites we will be creating the tunnel between are Site A and Site B.

Here is an overview of the network:

GRE-overview

Site A

CLI Commands:

config system gre-tunnel
edit “GRE-to-SITEB”
set interface “WAN1”
set remote-gw 2.2.2.1    — Remote firewall WAN IP
set local-gw 1.1.1.1          — Local FW WAN1 IP
next
end

config system interface
edit “GRE-to-SiteB”
set vdom “root”
set ip 192.168.254.1 255.255.255.255    — Local Tunnel IP
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2                  — Remote Tunnel Endpoint IP
set snmp-index 65
set interface “WAN1”
next
end

GRE-overview.JPG

Route Creation

From here we can create the static route pointing my remote traffic (10.2.2.0/24) through the GRE-to-SITEB GRE tunnel.

Route-SiteA

Firewall Policy Creation

Next, we need to create the firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface (or whichever interface on which your traffic originates).

Policy-SiteA

 

Site B

CLI Commands:

config system gre-tunnel
edit “GRE-to-SITEA”
set interface “wan1”
set remote-gw 2.2.2.1
set local-gw 1.1.1.1
next
end

config system interface
edit “GRE-to-SITEA”
set vdom “root”
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1
set snmp-index 8
set interface “wan1”
next
end

Route Creation

Now we can create the static route pointing my remote traffic (10.1.1.0/24) through the GRE-to-SITEA GRE tunnel.

Route-SITEB

Firewall Policy Creation

Next we need to create the firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.

Policy-SiteB

That should be it!

Now We Test

Now let’s see if we can ping across our tunnel. As shown below, pings work great! Pinging both the tunnel interface and across the tunnel are great ways to check if it’s actually working. Odds are if you have enabled ping on the tunnel interface, and cannot ping it from the other side then the tunnel is not working. Also, check the firewall policy count to ensure it increases with traffic, which it should if everything is working.

site-a-pings

site-a-count

This is the time where you can enable IPsec encryption layer. There is so much more you can do (or may have to do) from here to cater the traffic’s behavior to your specific environment.

If you have questions about configuring your GRE tunnel or about FortiGates in general, you can email us or give us a call at 502-240-0404!