GRE
Note
The new GRE page is currently in Beta. Contact your Sales Representative or Support to enable it. If you're using the previous GRE page, see GRE.
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.
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.
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 GRE tunnel drops the probe packets.
Ensure you install the Netskope Client 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 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.
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.
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.
: 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 Netskope POP associated with the GRE site. Click View Additional Pops to view the backup POPs.
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.
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 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.