Fortinet black logo

Handbook

Configuring GRE tunnel endpoint addresses

Copy Link
Copy Doc ID 7b437c33-fcc7-11ec-bb32-fa163e15d75b:280282
Download PDF

Configuring GRE tunnel endpoint addresses

Overview

If you are using always-on or on-demand cloud DDoS mitigation, in most cases the Service Provider will return clean traffic to you via a GRE tunnel. Since the GRE tunnel encapsulates all other traffic, it can mask anomalies and other attack traffic missed by the cloud provider. Using the GRE tunnel endpoint feature, FortiDDoS can process this traffic to give you an identical graphical view and complete mitigation for the original packets.

This feature can also be used to monitor other Point-to-Point GRE tunnels you may use.

To monitor GRE tunnels

  1. Go to Global Protection > GRE Tunnel Endpoint.
  2. Click Create New.
  3. Enter the settings according to the table below for both the service provider IPs and your terminating IPs. Click Save.
  4. The entries will be displayed on the GRE Tunnel Endpoint list page.

Setting

Description

Name

a-Z, 0-9, _, - only (no spaces)

IP Version

IPv4 or IPv6

IP Address

IPv4 or IPv6 address of:

  • Source IP (outside) public IP address(es) of the Service Provider’s GRE tunnel(s).
  • Destination (your protected) public IP address(es) of the device (usually your firewall) terminating the GRE tunnel(s).

Note:

  • These addresses must not be part of the /24 subnet that is diverted to the Cloud DDoS service provider
  • IP address with no netmask (assumed /32)

Since any IP addresses terminating the GRE tunnel on your firewall are public IP addresses, there is some risk they could be attacked if the attacker can discover the addresses.

We recommend that you create a separate SPP for your GRE terminating IPs.

  1. Create a new Service Protection > Service Protection Policy.
  2. Save, Edit and Add Protection Subnets for your terminating IP address(es). Do not include the Service Provider’s IP addresses. Your GRE IPs should be the only IPs or subnets in this SPP.
    1. Configure this SPP to system minimum Thresholds. This can be done by running Traffic Statistic for a 1-hour period and setting System Recommendations. Since there is normally no traffic on this SPP, the Thresholds will be set to the default Minimums.
    2. Set Protocol 47 (GRE) Thresholds to system maximums in both directions. You may want to adjust this threshold to 3x actual traffic but you will only be able to see GRE traffic when the Cloud DDoS Mitigation service is sending GRE traffic.
  3. Consider ACLing all Protocols except 1 for ICMP and 6 for BGP signaling via TCP. Consider ACLing all TCP ports except 179 (BGP) and set the ICMP Protocol rate threshold under 100pps.

    None of the GRE-encapsulated “inner” traffic will be seen on this SPP, since it will be assigned to SPPs based on the inner IP address headers.

  4. You will see the “outer” GRE traffic for this SPP in Monitor > Layer 3/4/7 > Layer 3 > Protocols. Enter Protocol 47.
Non-FortiDDoS Requirements:
  • It is important to ensure that your network MTU/MSS is set correctly to prevent significant fragmentation of arriving traffic with the added GRE overhead. Normally, both MTU and MSS must be lowered to prevent fragmentation of TCP and UDP packets, but please discuss with your Cloud DDoS Mitigation Service Provider.
  • Check that Path MTU is working end-to-end through the GRE tunnel.
  • Determine if your cloud mitigation service provider will use Direct Server Response (normal) where outbound traffic will be sent via your local ISP or routing mode (Inbound and outbound traffic in GRE).

    Ensure that your firewall is capable of decapsulating the full inbound normal data rate of your clean traffic (Direct Server Return) or total traffic (Routing Mode).

Operation

When the system sees GRE traffic destined to one of the defined GRE Endpoint IP addresses in the list and the Source also matches an IP address in the list, it does the following:

  • Always allows the GRE packet.
  • Inspects the “inner” L3/L4/L7 headers of the GRE packet, which is the original packet, and assigns the traffic to the Protection Subnet and SPP as it normally would for non-GRE traffic. All settings and thresholds as configured for the SPP, are used for these SPPs. Monitor graphs, logs, reports and so on will all operate on this 'clean' traffic as if it was the only traffic present. If the Cloud Mitigation Service Provider has missed any mitigations, they will be performed on this traffic, determined by the SPP Detection or Prevention Mode, with appropriate graphs and logs.
  • Displays the ingress/egress GRE traffic in the Monitor > Layer 3/4/7 > Layer 3 > Protocol 47 graph.
  • If the system sees GRE traffic destined to an IP that is not matched by another address in the Endpoint list, it will treat it as normal traffic and assign it to the appropriate SPP as GRE protocol 47 traffic without further inner header inspection.

Configuring GRE tunnel endpoint addresses

Overview

If you are using always-on or on-demand cloud DDoS mitigation, in most cases the Service Provider will return clean traffic to you via a GRE tunnel. Since the GRE tunnel encapsulates all other traffic, it can mask anomalies and other attack traffic missed by the cloud provider. Using the GRE tunnel endpoint feature, FortiDDoS can process this traffic to give you an identical graphical view and complete mitigation for the original packets.

This feature can also be used to monitor other Point-to-Point GRE tunnels you may use.

To monitor GRE tunnels

  1. Go to Global Protection > GRE Tunnel Endpoint.
  2. Click Create New.
  3. Enter the settings according to the table below for both the service provider IPs and your terminating IPs. Click Save.
  4. The entries will be displayed on the GRE Tunnel Endpoint list page.

Setting

Description

Name

a-Z, 0-9, _, - only (no spaces)

IP Version

IPv4 or IPv6

IP Address

IPv4 or IPv6 address of:

  • Source IP (outside) public IP address(es) of the Service Provider’s GRE tunnel(s).
  • Destination (your protected) public IP address(es) of the device (usually your firewall) terminating the GRE tunnel(s).

Note:

  • These addresses must not be part of the /24 subnet that is diverted to the Cloud DDoS service provider
  • IP address with no netmask (assumed /32)

Since any IP addresses terminating the GRE tunnel on your firewall are public IP addresses, there is some risk they could be attacked if the attacker can discover the addresses.

We recommend that you create a separate SPP for your GRE terminating IPs.

  1. Create a new Service Protection > Service Protection Policy.
  2. Save, Edit and Add Protection Subnets for your terminating IP address(es). Do not include the Service Provider’s IP addresses. Your GRE IPs should be the only IPs or subnets in this SPP.
    1. Configure this SPP to system minimum Thresholds. This can be done by running Traffic Statistic for a 1-hour period and setting System Recommendations. Since there is normally no traffic on this SPP, the Thresholds will be set to the default Minimums.
    2. Set Protocol 47 (GRE) Thresholds to system maximums in both directions. You may want to adjust this threshold to 3x actual traffic but you will only be able to see GRE traffic when the Cloud DDoS Mitigation service is sending GRE traffic.
  3. Consider ACLing all Protocols except 1 for ICMP and 6 for BGP signaling via TCP. Consider ACLing all TCP ports except 179 (BGP) and set the ICMP Protocol rate threshold under 100pps.

    None of the GRE-encapsulated “inner” traffic will be seen on this SPP, since it will be assigned to SPPs based on the inner IP address headers.

  4. You will see the “outer” GRE traffic for this SPP in Monitor > Layer 3/4/7 > Layer 3 > Protocols. Enter Protocol 47.
Non-FortiDDoS Requirements:
  • It is important to ensure that your network MTU/MSS is set correctly to prevent significant fragmentation of arriving traffic with the added GRE overhead. Normally, both MTU and MSS must be lowered to prevent fragmentation of TCP and UDP packets, but please discuss with your Cloud DDoS Mitigation Service Provider.
  • Check that Path MTU is working end-to-end through the GRE tunnel.
  • Determine if your cloud mitigation service provider will use Direct Server Response (normal) where outbound traffic will be sent via your local ISP or routing mode (Inbound and outbound traffic in GRE).

    Ensure that your firewall is capable of decapsulating the full inbound normal data rate of your clean traffic (Direct Server Return) or total traffic (Routing Mode).

Operation

When the system sees GRE traffic destined to one of the defined GRE Endpoint IP addresses in the list and the Source also matches an IP address in the list, it does the following:

  • Always allows the GRE packet.
  • Inspects the “inner” L3/L4/L7 headers of the GRE packet, which is the original packet, and assigns the traffic to the Protection Subnet and SPP as it normally would for non-GRE traffic. All settings and thresholds as configured for the SPP, are used for these SPPs. Monitor graphs, logs, reports and so on will all operate on this 'clean' traffic as if it was the only traffic present. If the Cloud Mitigation Service Provider has missed any mitigations, they will be performed on this traffic, determined by the SPP Detection or Prevention Mode, with appropriate graphs and logs.
  • Displays the ingress/egress GRE traffic in the Monitor > Layer 3/4/7 > Layer 3 > Protocol 47 graph.
  • If the system sees GRE traffic destined to an IP that is not matched by another address in the Endpoint list, it will treat it as normal traffic and assign it to the appropriate SPP as GRE protocol 47 traffic without further inner header inspection.