Skip to main content

Netskope Help


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 endpoint. 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 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.

Best Practices

To use GRE:

  • You must have the Netskope Secure Web Gateway or Netskope Cloud Firewall license.

  • Configure your source device to establish the GRE tunnel. See your router or firewall documentation for instructions. 

  • 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. See your firewall documentation for instructions.

  • 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.


    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 and 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 in 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.

  • The GRE gateway node can respond to ICMP probes/keep-alives 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 probe packets are dropped by GRE.

  • Ensure the Netskope Client is installed on your users' devices. If not, go to Settings > Manage > Certificates to download the Netskope root certificate and distribute it to your users' devices. This prerequisite 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.


The primary steps to configure GRE include:

  1. Configure GRE in the Netskope UI.  

  2. Configure the GRE tunnel from the source device so that a primary and a failover exists. You can configure as many GRE tunnels as needed from the sites that you tunnel traffic from. Each tunnel supports up to 1 Gbps throughput.

  3. Install the Netskope Client or provision the Netskope root certificate on devices.

  4. Choose steering/identity options.

Configure GRE in the Netskope UI

You must add the IP addresses of your source devices (e.g., router, firewall, etc.) in the Netskope UI and copy the Netskope point of presence (POP) IP addresses to establish GRE tunnels on your devices.

  1. Go to Settings > Security Cloud Platform > GRE.

  2. Click New GRE Configuration.

  3. In the New GRE Configuration window:

  4. Enter the source peer IP address (exit public IP) of your router/firewall that Netskope will receive packets from. Netskope identifies traffic belonging to your organization through your router/firewall IP addresses.

  5. Click Save and View POPs. Copy the Netskope points of presence (POP) IP addresses for the two locations closest to you. You will need this information to establish GRE tunnels on your devices.


After a tunnel has been established on your devices, the tunnel appears in the table on the GRE page. The table shows the configuration name, source peer, Netskope POP(s), user traffic status, keepalive status, and throughput in kilobytes per second (Kpbs). The user traffic status types are Seen and Unseen.

Click on a tunnel name to edit the GRE tunnel configuration. Also, click the MenuIcon.png icon to the right of the tunnel listing to edit, enable, disable, or delete the tunnel.

You can also search for tunnel configuration using the filters for source peer, Netskope POP, User Traffic Status, and Keepalive Status.

Configure GRE Tunnels on Source Device

Netskope recommends configuring two GRE tunnels from your location to the Netskope POPs. This ensures high availability for tunneling traffic through GRE. Here is an example of how to configure your GRE tunnels:

  1. Configure your router/firewall for GRE. Refer to Deploying GRE Tunnels and Monitoring GRE Tunnels below for specifics.

  2. Configure the GRE tunnels to direct HTTP(s) (for Netskope Secure Web Gateway) and/or non-HTTP(s) (Netskope Cloud Firewall) traffic to the Netskope POPs. 

  3. Traffic is directed through the Netskope cloud. 

Deploying GRE Tunnels

Create two GRE tunnels for each egress location in your network. Having two GRE tunnels ensures that connectivity is maintained in the event of an outage on the primary tunnel. The backup GRE tunnel takes over until the primary GRE tunnel gets restored. The backup tunnel must be connected to a different Netskope POP than the primary one.

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


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.

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 use a GRE packet with the source and destination IP addresses reversed to be sent as the inner payload from the source peer. 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.

    Keepalive on Juniper devices use an ICMP packet with the endpoint’s inner IPs to be sent over the GRE tunnel. These inner IPs are allocated by Netskope so that Netskope GRE gateway can be configured to respond that 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.

If the Netskope GRE gateway doesn't observe a keepalive packet within a minute, the tunnel probe status will be flagged as down, and the GRE service will update the keepalive status as Not Seen in the Netskope UI. 

Traffic Steering and Identity Options

To steer traffic and identify users, use one or more of these method.

Install the Netskope Client for Root CA Distribution, User Identity, and User Notifications

Optionally, Netskope recommends installing the Netskope Client to facilitate certificate distribution on devices and provide coverage for remote users. The Netskope Client provides user identification directly to Netskope and eliminates the need to implement authentication on the GRE tunnel.

If you install the Netskope Client, it can send device and user info to the Netskope Cloud and show user-facing notifications that result from policy violations. To do this, go to Settings > Security Cloud Platform > Devices > Client Configuration and enable the feature Enable Device Classification and Client-Based End User Notifications when the Client is Disabled. When the Client detects a GRE tunnel, it disables the data tunnel (TLS tunnel) to the Netskope platform, but continues sending user identity to Netskope and facilitating user notifications on the endpoint. You can only view the latest user login information.

Provision Certificates on Devices

Certificates only need to be provisioned on devices that do not have the Netskope Client installed. Get the root certificate from the Netskope UI and provision it on your devices. In the Netskope UI, go to Settings > Manage > Certificates to download the certificates.  Check the product documentation for your devices to learn how to provision the certificates.

Use SAML Authentication

If you don't use the Netskope Client, you can use SAML to authenticate a user with your Identity Provider (IdP) before their traffic is tunneled via GRE. Use Netskope as an authentication mode to integrate with an IdP.

Enable Authentication

You can use SAML to authenticate a user to Netskope before their connection is allowed to traverse the GRE tunnel. Use Netskope as an authentication mode to integrate with an Identity Provider (IdP). This feature acts as an authentication module taking Netskope's framework and an IdP's auth assertion after authentication.

  1. Go to Settings > Security Cloud Platform > Forward Proxy > Authentication.

  2. Click Enable Authentication.

  3. Click the Enabled checkbox to turn this feature on.

  4. Click Create New for SAML based authentication. The Add SAML Account window opens.

  5. Configure these parameters:

    • Name: Enter a name identifying the account.

    • IdP URL: Contact your third party Identity Provider and add the unique IdP login URL in this field.

    • IdP Entity ID:  Type your globally unique name for your SAML entity.

    • IdP Certificate: Copy and paste the PEM format certificate of the third party IdP in this field. This is required by Netskope to validate the signature of the SAML assertion.

    • Alternate User ID Field: Netskope looks at the NameID field in the SAML assertion to get the user identity. If you would like to use another field for user identification, type the name of the SAML attribute in this field.

    • Group Attribute: Type your name:value pair to identify / describe your entities user group and role memberships.

  6. Click Save.

Authentication Bypass Settings

You can specify domains, web categories, and network IP addresses for which user authentication is not required.

Domain Bypass

Click Edit and add comma-separated URLs to bypass. When finished, click Save.



Adding your IdP domains here are recommended.

Web Category Bypass

Click Edit and add comma-separated URLs to bypass. When finished, click Save.

IP Address Bypass

Click Edit and search for source networks. For each of the networks found, you can choose to bypass based on User IPs or Egress IPs (just one, not both).


If search does not locate the network you want to bypass, click +New to add it.


Enter the IP address, IP address range, or CIDR netmask in the text field, and then click the adjacent + button. Multiple network locations can be added. After adding the network locations, click Next, enter a name, and then click Save Network Location.

Select User IP or Egress Source IP for each network location, and then click Save.


Certificate Issues:

  • If you are seeing a certificate error in browser, check the Netskope certificate on the browser, make sure the Netskope root certificate is installed on the  end-user devices.

Connection issues: 

If end-to-end traffic is not working:

  • Check if the GRE tunnel status to see if it is up on the exit router.

  • Check the tunnel interface counters to see if they are going up or not, which would indicate the transit of traffic.

  • If a tunnel is down, check to make sure the GRE/ICMP keepalives sent by the exit router is receiving the keepalive response back. 

  • If a tunnel is down, end-to-end traffic should be working through the router's default-gateway.

  • If the tunnel is up, check the route-map configured to re-direct the traffic.

  • Make sure the firewall is allowing GRE traffic.

  • Make sure the router exit IP (public IP) is added to the GRE page from Netskope console (tenant UI).

  • Route map should ideally be configured to redirect port 443/80 over the GRE Tunnel.

  • Contact Netskope Support.

Performance issues:

  • Check the MTR against the Netskope GRE IP address. It should show RTT between your environment to the Netskope Cloud. It will also show packet drops.

  • Capture packets at the endpoint egress interface using Wireshark. It will show complete TCP statistics.

GRE device status:

  • Login into the source peer device to determine the GRE tunnel status. If the tunnel is down, there is high chance that the device is not able to communicate with Netskope GRE service, or this GRE node/site is not yet provisioned. Go to the Netskope GRE page to confirm.