Generic Routing Encapsulation (GRE) is a tunneling protocol for encapsulating packets inside a transport protocol. A GRE tunnel functions like a VPN but without encryption; it transports packets from one endpoint to another. A GRE capable router/firewall encapsulates a payload packet inside a GRE packet, which it then encapsulates in a transport protocol, such as IP, and sends it over the internet.
GRE can steer HTTP(S) and non-HTTP(S) traffic to the Netskope cloud. The Netskope GRE gateway validates the source IP of the tunnel as a known IP address which must be configured in the Netskope UI.
The following diagram illustrates the traffic workflow for GRE tunnels with Netskope Secure Web Gateway:
Additionally, if you have Netskope Cloud Firewall, you can steer non-HTTP(S) traffic through the GRE tunnels to the Netskope cloud:
General Guidelines
When creating or editing a GRE tunnel, consider the following::
- You must have the Netskope Secure Web Gateway or Netskope Cloud Firewall license.
- Configure your source device to establish the GRE tunnel. To learn more, see your router or firewall documentation.
- Configure your firewalls, if any, to allow the GRE tunnel. If your firewall has an ACL blocking inbound connections, configure a rule to allow GRE traffic. To learn more, see your firewall documentation.
- Configure your peer device to have the tunnel destination set as the VIP of Netskope POP that you configured in Netskope UI/API. If you configure a GRE tunnel to a POP that isn’t configured in Netskope UI/API, then it won’t come up.
- If you are configuring Netskope Secure Web Gateway, only send HTTP (port 80) and HTTPS (port 443) through the GRE tunnel. You can also use non-standard or custom ports for HTTP and HTTPS traffic.
Note
Netskope negotiates HTTP/2 for all domains if the origin server supports it; otherwise, Netskope fallbacks to HTTP 1.1. All other traffic will continue to leverage HTTP 1.1. In addition, the Netskope Client, GRE/IPSEC, and iOS access methods are fully supported. The protocol change is completely transparent to users, no configuration is required by admins. Contact Support to enable this feature for your account.
- If you are configuring Netskope Cloud Firewall, send non-HTTP(S) traffic through the GRE tunnel. You can also use non-standard or custom ports for HTTP(S) traffic.
- You cannot implement NAT for endpoints inside the GRE tunnel. If your source peer network uses NAT based on an endpoint IP address, the Netskope GRE service will observe only one IP address, and that will impact GRE load balancing, performance, reporting, and policy granularity. Your source peer network should not implement NAT on endpoint IP address.
- Netskope strongly recommends enabling ICMP keepalive probing for each tunnel on the router or firewall. Enabling this feature ensures a reliable status output in the Netskope UI especially if tunnel failure occurs. Netskope also recommends probing every 20 seconds and retrying 5 times every 6 seconds (if the vendor permits). If you have more than one tunnel connecting to the same POP, you must randomize the probe timeouts to prevent the probes from landing on the same interval. For example, if you have three tunnels connected to the SFO1 Netskope POP, you should set the probing intervals for each one as 20 5 6, 19 6 6, and 22 5 6.
- The GRE gateway node can respond to ICMP probes/keepalives only when the destination IP value in the inner IP packet matches the GRE gateway probe IP listed in the GRE gateway UI Dashboard corresponding to the Netskope POP. Otherwise, the GRE tunnel drops the probe packets.
- When health checks for downstream services like Netskope Cloud Firewall or Netskope Secure Web Gateway are down, the GRE tunnel goes down and new tunnel establishments fail sending a GRE AUTH FAILURE message.
- Endpoints must have Netskope’s root and intermediate certificates trusted so Netskope can perform SSL decryption for web traffic properly. If you install the Netskope Client on your user’s devices, it automatically installs the appropriate certificates. Alternatively, you can go to Settings > Manage > Certificates > Signing CA to download the Netskope root and intermediate certificates to distribute to your endpoints. This is optional for Netskope Cloud Firewall.
- Calculate the maximum segment size (MSS) to account for GRE headers on the WAN interface. If you don’t set an MSS, it can negatively impact tunnel performance.
- Netskope recommends having traffic from the endpoint at least every 30 minutes.
- Traffic from same user or endpoint must go through the same tunnel, and you can’t load balance it across tunnels.
- You must configure failover to a backup tunnel to ensure minimal connection interruptions.
Note
You must regularly test your failover IPSec tunnel, as traffic redirection to a failover tunnel occurs on your GRE gateway outside Netskope’s visibility and control.
- Any application sending traffic over a GRE tunnel must be able to handle a switchover event from the primary to failover tunnel gracefully. If an application isn’t capable of handling this type of switchover event, you shouldn’t send the that application’s traffic over a GRE tunnel.
- GRE is stateful protocol by nature. During periodic planned maintenances, expect the tunnel to go down and come up briefly as the GRE software gets upgraded.
High-Capacity GRE Tunneling
Netskope supports high-bandwidth capacity for your primary and backup GRE tunnels, providing high-performance connections between your source devices and Netskope for heavy traffic demands. The following high-capacity GRE tunnels are supported:
| Bandwidth | Requirements |
|---|---|
| 3 Gbps | Licensed. Requires capacity evaluation. |
| 5 Gbps | Licensed. Requires capacity evaluation. |
Key Considerations
-
The above bandwidth is peak aggregated throughput at any time (i.e., the total sum of upload and download traffic).
-
The bandwidth is qualified based on IMIX traffic profile with average packet size of 620 Bytes. Any other test profile might not be able to provide the same performance.
-
High-capacity tunnels are offered with Primary and Failover POP in an active-standby tunnel configuration. Additional POPs aren’t supported with high-capacity tunnels.
-
If you’re upgrading the bandwidth of an existing tunnel to high-capacity (e.g., 250 Mbps to 3 Gbps), then the tunnel will go down and come up, which might cause some traffic loss. To prevent this, ensure you notify Netskope immediately since it requires a configuration update that must be planned through a maintenance window.
Netskope offers this capability based on capacity evaluation and expansion. There might be provisioning lead time of up to 6 weeks depending on the available resources at a given Netskope POP. To ensure faster provisioning, you must share the following information with your Netskope Sales Representative at least 6 weeks in advance:
| Tunnel Pairing | Source IP Address | Primary POP | Failover POP |
|---|---|---|---|
| Tunnel-Pair-1 | a.b.c.d | NYC3 | NYC4 |
| Tunnel-Pair-2 | w.x.y.z | ORD2 | ORD4 |
Changing the Source IP Address
When configuring your GRE sites, ensure you provide the Source IP Address in Basic Settings.
If the source IP changes, you must notify Netskope immediately since it requires a configuration update that must be planned through a maintenance window.
Calculating the MTU & MSS
Calculate the maximum transmission unit (MTU) and maximum segment size (MSS) needed for your GRE tunnels based on the configuration of your WAN interface. If the MTU isn’t properly calculated, higher fragmentation can occur and impact performance.
Here is a sample MTU and MSS calculation for a WAN interface with 1500 bytes:
WAN Interface MTU = 1500 WAN Interface MSS = MTU (1500) - IP (20 bytes header) - TCP (20 bytes header) = 1460 GRE = 4 bytes header GRE MTU = MTU (1500) - IP (20) - GRE (4) = 1476 GRE MSS = GRE MTU (1476) - IP (20) - TCP (20) = 1436
MTU Recommendation
- If you’re using Cloud Firewall, you must set the L3 MTU size to 1476 bytes on the client devices. The MTU value on the router or firewall can continue with the default MTU value of 1500 bytes.
- Netskope recommends you allow the UDP applications on the client devices to support path MTU discovery (PMTUD) to avoid IP fragmentation if the MTU value isn’t changed to 1476 bytes.
- If the IP packet size exceeds 1476 bytes and has the Don’t Fragment (DF) bit set, the Netskope GRE gateway drops the packet and sends the client an ICMP destination unreachable message with a code indicating “fragmentation needed and DF set”. If the IP packet doesn’t have the DF bit set, Netskope GRE gateway silently drops the packet.
TCP MSS Recommendation
Netskope GRE gateway adjusts MSS automatically for TCP traffic.
Configuring GRE Tunnels
Netskope must configure GRE tunnels from your router/firewall to at least two different Netskope POPs. This ensures the connectivity is maintained for tunneling traffic through GRE in the event one of the two identity source peers is temporarily not available. The backup GRE tunnel takes over until the primary tunnel gets restored.
To configure GRE tunnels for your organization:
- Configure the GRE tunnels in the Netskope UI to direct traffic to the the Netskope POPs. The POP addresses are available in the Netskope admin console at Settings > Security Cloud Platform > Traffic Steering > GRE > Netskope POPs. To learn more: Creating a GRE Site.
- Configure the GRE tunnels for your vendor’s source identity devices. Each tunnel supports up to 1 Gbps throughput. Use policy-based routing to steer HTTP/HTTPS traffic on ports 80 and 443 through the GRE tunnels. If you have the Cloud Firewall license, you can also steer non-HTTP(s) traffic like TCP, UDP, and ICMP through the tunnels. To see vendor specific integration guides: IPSec and GRE.
- After configuring the GRE tunnels, choose steering/identity options, such as installing the Netskope Client or provisioning the Netskope root certificate on devices. To learn more: User Identity Methods for IPSec and GRE Tunnels.
Monitoring GRE Tunnels
Monitor your GRE tunnels to ensure failover between the primary and backup GRE tunnels. Enable GRE keepalives as a basic detection mechanism.
- For Cisco routers, you can use IPSLA or keepalive on the Cisco tunnel interface to monitor the tunnels.
The keepalives on Cisco devices sends a GRE packet as the inner payload from the source peer containing the source and destination IP addresses reversed. The GRE destination relays the inner packet to indicate the tunnel is up.
- For Juniper routers, you can use RPM or keepalive to monitor the tunnels.
The keepalives on Juniper devices sends an ICMP packet over the GRE tunnel containing the endpoint’s inner IP addresses. Netskope allocates these inner IP addresses so the Netskope GRE gateway can be configured to respond when the tunnel is up.
For high-availability, the keepalives enable GRE endpoints to failover to a backup tunnel if a response isn’t received. The Netskope GRE gateway sends back a keepalive response only if there are no health check issues with the tenant specific proxy.
Netskope recommends probing every 20 seconds and retrying 5 times. If the vendor permits, Netskope also recommends setting the retry probe interval to occur every 6 seconds for a lost/unanswered probe. For example:
| Time (Seconds) | Event | Tunnel Status |
|---|---|---|
| 0 | GRE tunnel is up. | Up |
| 20 | Probe received & responded. | Up |
| 40 | Probe received & responded. | Up |
| 60 | Probe not received to Netskope or the probe response didn’t make it to tenant. | Up |
| 66 | Retry #1: Probe still not received. | Up |
| 72 | Retry #2: Probe still not received. | Up |
| 78 | Retry #3: Probe still not received. | Up |
| 84 | Retry #4: Probe still not received. | Up |
| 90 | Retry #5: Probe still not received. | Up |
| 91 | Netskope updates the tunnel status to down. | Down |
If you have more than one tunnel connecting to the same POP, you must randomize the probe timeouts to prevent the probes from landing on the same interval. For example, if you have three tunnels connected to the SFO1 Netskope POP, you should set the probing intervals for each one as 20 5 6, 19 6 6, and 22 5 6.
If the Netskope GRE gateway doesn’t observe a keepalive packet within a minute, the tunnel probe status is flagged as down, and the GRE service updates the keepalive status as Not Seen in the Netskope UI.
About the GRE Page
On the Steering Configuration page (Settings > Security Cloud Platform > GRE), you can:
- Refresh the GRE site configurations.
- Search and filter the GRE sites by name. Click + Add Filter to add other filters to narrow your search results by:
- Source Identity
- Status
- Netskope POP
- Traffic Type
- Create a new GRE site or import multiple GRE sites using a CSV file.
- View the Netskope POP list and the following information for each one:
- Gateway: The gateway IP address.
- Probe IP Address: The probe IP address.
- Location: Its geographical location.
You can also see if a Netskope POP isn’t accepting new tunnels.
- View a list of GRE sites. For each site, you can see the following information:
- Name: The name of the GRE site.
- Source Identity: Not applicable for GRE sites.
- Source IP Address: The source peer IP address (i.e., exit public IP) of the router or firewall that Netskope will receive packets from. Netskope identifies traffic belonging to your organization through your router or firewall IP addresses.
- Status: The status of the GRE site.
: The GRE site is observing keepalive packets from the router or firewall.
: In the last minute, the GRE site hasn’t observed any keepalive packets from the router or firewall. If the tunnel is down, Netskope continues to process the tunnel packet.
: There is a delay getting the latest GRE tunnel status. This can occur if the underlying infrastructure hosting the GRE service is under maintenance. To learn more, check the Trust Portal, or contact your Netskope representative.
: The GRE site is disabled.
If you hover over the status, you can also see the following keepalive information:
- Keepalive Status: Displays the keepalive connections as Seen or Unseen only if you configured keepalives for the GRE site.
- Keepalive Last Updated: Displays the time since Netskope has seen the keepalive connection. If no time is displayed, Netskope doesn’t see keepalive packets.
You can enable your tunnel as a permanent tunnel. However, to ensure the Netskope UI displays reliable tunnel states, especially if a tunnel failure occurs, Netskope recommends enabling ICMP keepalive probing for each tunnel on the device, including the failover to the backup tunnel.
- Netskope POP: The primary and backup Netskope POPs associated with the GRE site. Click View Additional Pops to view any additional POPs configured for the site.
- Throughput: The GRE site throughput in kilobytes per second (Kbps). If you hover over the throughput, you can also see:
- User traffic last updated: Displays the time since Netskope has seen user traffic. If no time is displayed, Netskope doesn’t see any traffic.
- Traffic Type: The type of traffic traversing the GRE site. You can use this option to classify your tunnel traffic and a build usage report.
- User
- IoT
- Mixed
- Machine
- Guest Wifi
- Sort the table by site name.
- Select at least one override using the checkbox and click Enable to enable it.
- Select at least one override using the checkbox and click Disable to disable it.
- Select at least one override using the checkbox and click Delete to delete it.
- Click
to customize table columns or restore the default ones. - Click
to choose one of the following options:- View Detail: View comprehensive details on the GRE site.
- Edit: Modify the GRE site and its settings. To learn more: Creating a GRE Site.
- Enable: Enable the GRE site.
- Disable: Disable the GRE site.
- Delete: Delete the GRE site.
- View Detail: View comprehensive details on the GRE site.
- View up to 100 sites per page.
- View multiple pages of the table.
Troubleshooting
Certificate Issues
- If you are seeing a certificate error in the browser, ensure the Netskope root certificate is installed on the user’s device.
Connection Issues
If end-to-end traffic is not working:
- Check the GRE tunnel status to see if it’s up on the exit router.
- Check the tunnel interface counters to see if they are going up or not, which indicates the transit of traffic.
- If a tunnel is down, ensure the GRE/ICMP keepalives sent from the exit router is receiving the keepalive response back.
- If a tunnel is down, check if end-to-end traffic is working through the router’s default-gateway.
- If the tunnel is up, check the route-map configured to redirect the traffic.
- Ensure the firewall is allowing GRE traffic.
- Ensure you added the router exit IP address (i.e., public IP address) to the GRE page in the Netskope UI.
- Ensure you configured the route map to redirect port 443/80 over the GRE Tunnel.
- Contact Netskope Support.
Performance Issues
- Check the MTR against the Netskope GRE IP address. It must show RTT between your environment to the Netskope cloud. It also shows packet drops.
- Use Wireshark to capture packets at the endpoint egress interface. It shows complete TCP statistics.
GRE Device Status
- Log in to the source peer device to determine the GRE tunnel status. If the tunnel is down, there is high chance that the device isn’t able to communicate with the Netskope GRE service, or this GRE node/site hasn’t been provisioned yet. Go to the Netskope GRE page to confirm.