Overview
The Generic Router Encapsulation (GRE) protocol is a simple, encapsulating protocol that can be used whenever there is a need to tunnel traffic across networks and/or through network devices.Using GRE
GRE is typically used to provide a method of connecting two networks together across a third network such as the Internet. The two networks being connected together communicate with a common protocol which is tunneled using GRE through the intervening network. Some examples of reasons to use GRE might be the following:Traversing network equipment that blocks a particular protocol.
Tunneling IPv6 traffic across an IPv4 network or tunneling IPv4 traffic across an IPv6 network.
Where a UDP data stream is to be multicast and it is necessary to transit through a network device which does not support multicasting, GRE can allow tunneling through the device.
GRE Security and Performance
A GRE tunnel does not use any encryption and is therefore not, in itself, secure. Any security must come from the protocol being tunneled. The advantage of GRE's lack of encryption is the high performance which is achievable because of the low traffic processing overhead.The lack of encryption might be acceptable in some circumstances if the tunneling is done across an internal network that is not public.
In cOS Stream, a GRE tunnel can be treated as a logical interface and has the same filtering, traffic shaping and other configuration capabilities as, for example, an Ethernet interface. Setting up a GRE tunnel requires the following steps:Create a new GRETunnel object. This requires at minimum, an IP address for both the local endpoint and the remote endpoint of the tunnel.
Add a Route to the main routing table that routes traffic destined for the remote network into the tunnel.
If required, add a Route that routes the tunnel endpoint IP address on the correct interface. This route is added to the routing table specified by the tunnel property RoutingTableMembership if it has been set. If it is not set, the main routing table is used by default.
![]() |
Caution: Check for possible looping in added routes |
---|---|
When configuring GRE routing, it is important to check that routes do not lead to looping of traffic. For example, outer GRE tunnel traffic routed back into the same tunnel. |
Mandatory GRETunnel Properties
The following properties are required as a minimum when configuring a GRETunnel object:LocalEndpoint
This is the IP address of the tunnel's local endpoint. The address type can be IPv4 or IPv6 but the type must match the type of the RemoteEndpoint property. However, the traffic inside the tunnel could be either IPv4 or IPv6, regardless of the endpoint IP type.
RemoteEndpoint
This is the IP address of the remote device which the tunnel will connect with.
Optional GRETunnel Properties
Some of the important optional properties that might be used with a GRE tunnel are the following:IPAddress
This is the IP address (either IPv4 or IPv6) of the local endpoint inside the tunnel on the local side. If not set, the default value is a zero address.
The specified IP address could be used for any of the following example purposes:
An ICMP Ping can be sent through the tunnel to this endpoint.
The source IP address of log messages sent through the tunnel from the local tunnel interface.
If NAT is being used then it will not be necessary to set the source IP on the IP rule that performs NAT on traffic going into the tunnel. This IP address will automatically be used as the source address for the outgoing traffic.
SourceInterface
The interface or interfaces on which to listen for incoming GRE flows. More than one interface can be specified by using an InterfaceGroup object.
If not specified, a value of any will be used for this property.
SessionKey
A unique integer number can optionally be specified for a tunnel. This allows more than one GRE tunnel to run between the same two endpoints with this value used to distinguish between them. The session key used by each tunnel peer must match.
RoutingTableMembership
This defines the routing table to be used for the traffic inside the tunnel. The Route object that is added to send the relevant traffic through the tunnel must be added to this routing table. If not specified, the main routing table will be used.
OuterRoutingTable
This defines the routing table to be used for the outer tunnel traffic. In other words, for the tunnel setup itself. If not specified, the main routing table will be used.
A list of all properties can be found under the GRETunnel entry in the separate CLI Reference Guide.
Network traffic coming from the GRE tunnel will be transferred to the cOS Stream main IP rule set for evaluation. The source interface of the network traffic will be the name of the associated GRE Tunnel.The same is true for traffic in the opposite direction, that is, going into a GRE tunnel. Furthermore a Route has to be defined so that cOS Stream knows which traffic should be sent through the tunnel.
A Typical GRE Scenario
The diagram below shows a typical GRE scenario, where two firewalls labeled A and B must communicate with each other through the intervening internal network 172.16.0.0/16.Any traffic passing between A and B is tunneled through the intervening network using a GRE tunnel. Since the network is internal and not passing through the public Internet, there is no need for encryption.
The setup for the two firewalls are described next.
Part 1. Setup for firewall A
Assuming that the network 192.168.10.0/24 is lannet on the lan interface, the steps for setting up cOS Stream on A are:In the address book set up the following IP objects:
Create a GRE Tunnel object called GRE_to_B with the following parameters:
Name | Action | Src Int | Src Net | Dest Int | Dest Net | Service |
---|---|---|---|---|---|---|
To_B | Allow | lan | lannet | GRE_to_B | remote_net_B | all_services |
From_B | Allow | GRE_to_B | remote_net_B | lan | lannet | all_services |
The CLI commands for firewall A setup are given in Example 3.7, “GRE Tunnel Setup”.
Part 2. Setup for firewall B
Assuming that the network 192.168.11.0/24 is lannet on the lan interface, the steps for setting up cOS Stream on B are as follows:In the address book set up the following IP objects:
Create a GRE Tunnel object called GRE_to_A with the following parameters:
Define a route in the main routing table which routes all traffic to remote_net_A on the GRE_to_A GRE interface.
Create the following entries in the main IP rule set that allow traffic to pass through the tunnel:
Name | Action | Src Int | Src Net | Dest Int | Dest Net | Service |
---|---|---|---|---|---|---|
To_A | Allow | lan | lannet | GRE_to_A | remote_net_A | all_services |
From_A | Allow | GRE_to_A | remote_net_A | lan | lannet | all_services |
Checking GRE Tunnel Status
IPsec tunnels have a status of being either up or not up. With GRE tunnels this does not apply. The GRE tunnel is considered established if it exists in the configuration.However, it is possible to get more information about a GRE tunnel by using the ifstat CLI command. For example, if a tunnel is called gre_interface then the following command can be used:
System:/>
ifstat my_gre_interface
Example 3.7. GRE Tunnel Setup
This example shows how to configure the GRE tunnel for firewall A from the setup scenario described previously in this section. The raw IP addresses will be used instead of references to address book objects.
Command-Line Interface
Add the GRE tunnel:
System:/>
add Interface GRETunnel GRE_to_B
LocalEndpoint=172.16.0.1
RemoteEndpoint=172.16.1.1
RoutingTableMembership=my_gre_rt
IPAddress=192.168.11.1
SessionKey=1
Add a route to send traffic to the remote network:
System:/>
cc RoutingTable my_gre_rtSystem:/RoutingTable/my_gre_rt>
add Route Interface=GRE_to_B Network=192.168.11.0/24
The tunnel GRE_to_A would be configured in a similar way on firewall B.