> Source: [sk169794](https://support.checkpoint.com/results/sk/sk169794) # sk169794 - GRE Configuration Guide | Property | Value | |----------|-------| | Solution ID | sk169794 | | Date Created | 2020-10-09 | | Last Modified | 2026-08-03 | | Technical Level | General | | Products | Security Gateway, Cloud Firewall, Scalable Platforms | | Versions | R82.10, R82, R81.20, R81.10 (EOS), R82.10, R81 (EOS), R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS), R81.10 (EOS), R81.20, R82 | | OS | Gaia | ## Solution **Table of Contents** 1. Overview 2. GRE Configuration Terminology 3. GRE Configuration in Gaia Portal 4. GRE Configuration in Gaia Clish 5. GRE Configuration by Topology * 5.1 GRE Configuration on a Single Gateway * 5.2 GRE Configuration on a Cluster * 5.3 GRE Configuration on a Traditional VSX Gateway * 5.4 GRE Configuration on a Traditional VSX Gateway with a Virtual Switch * 5.5 GRE Configuration on a Traditional VSX Gateway with a Virtual Router * 5.6 GRE Configuration on a Traditional VSX Cluster * 5.7 GRE Configuration on a Traditional VSX Cluster with a Virtual Switch * 5.8 GRE Configuration on a Traditional VSX Cluster with a Virtual Router 6. GRE Monitoring using IP Reachability Detection 7. GRE and Policy Based Routing (PBR) with a Firewall Rule using Updatable Objects 8. Troubleshooting 9. Common Setup Issues 10. GRE Limitations (1) Overview {#Overview} ------------------------ > GRE is a tunneling protocol that encapsulates packets over an IP network. > > Check Point Security Gateways / Clusters support GRE from R81. > > Check Point Scalable Platforms support GRE from R82. > > Important - GRE interfaces are not secure because they are not encrypted. (2) GRE Configuration Terminology {#Terminology} ------------------------------------------------ > |-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | **Term** | **Usage** | > | **ID** | An identifying number for the GRE interface. It can be 1-1024. The ID must not overlap with another GRE interface's ID number. This ID is used for naming purposes only. | > | **Local IP Address** | The IP address of the underlying interface on this Gateway. | > | **Remote IP Address** | The IP address of the remote Gateway where the tunnel terminates. | > | **TTL** | The "Time to Live" field of the packet. | > | **IP Address** | The assigned IPv4 address of the GRE interface. | > | **Mask** | The mask length of the IP address given in the "IP address" field. | > | **Peer Address** | The peer to peer address of the GRE interface, or the address of the terminating GRE interface on the remote Gateway. When you add a route over a GRE interface, this IP address may be used as the Gateway IP address. | (3) GRE Configuration in Gaia Portal {#Gaia_Portal} --------------------------------------------------- > #### Adding a GRE Interface: > > > 1. Log in to the Security Gateway / Cluster Member's Gaia Portal at: > > > > **https://\** > > 2. Go to **Network Management** \> **Network Interfaces** \> . > > > > 3. Click **Add** \> **GRE**. > > > > Enter the information to set up a GRE tunnel. Refer to the "GRE Configuration Terminology" section above for details about GRE fields. > > > > **Note**: It is supported to configure a GRE interface over a bond interface. > > 4. Click **OK**. > > #### Deleting a GRE Interface: > > > 1. Log in to the Security Gateway / Cluster Member's Gaia Portal at: > > > > **https://\** > > 2. Go to **Network Management** \> **Network Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. (4) GRE Configuration in Gaia Clish {#Gaia_Clish} ------------------------------------------------- > Enter all commands on the command line in Gaia Clish on the Security Gateway / each Cluster Member. > > See the "GRE Configuration Terminology" section above for details about GRE fields. > > ### Adding a GRE Interface > > > `add gre id local remote ttl ip mask peer ` > > > > `save config` > > > > Example: > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > ### Deleting a GRE Interface > > > `delete gre id ` > > > > `save config` > > > > Example: > > > > `delete gre id 1` > > > > `save config` > > ### Viewing GRE configuration > > > `show configuration gre` (5) GRE Configuration by Topology {#Topology} --------------------------------------------- ### (5.1) GRE Configuration on a Single Gateway {#SingleGW} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/SingeGW-gre-config202010021334571.png) > > #### Adding a GRE Interface on a Single Security Gateway > > > 1. Configure the GRE interface on the Security Gateway in Gaia Portal or in Gaia Clish with this command: > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 2. On the Security Gateway, configure the applicable nexthop address to be the address of the GRE interface on the opposite end of the tunnel. > > > > 3. In SmartConsole, open the Security Gateway object. > > > > 4. Go to **Network Management**. > > > > 5. Click **Get Interfaces** \> **Get Interfaces with Topology**. > > > > 6. The new GRE interface now appears in the table. Click **OK**. > > > > 7. Install the Access Control Policy on the Security Gateway. > > #### Deleting a GRE Interface on a Single Security Gateway > > > 1. Delete the GRE interface on the Security Gateway in Gaia Portal or in Gaia Clish with this command: > > > > `delete gre id 1` > > > > `save config` > > 2. In SmartConsole, open the Security Gateway object. > > > > 3. Go to **Network Management**. > > > > 4. Click **Get Interfaces** \> **Get Interfaces with Topology**. > > > > 5. Install the Access Control Policy on the Security Gateway. ### (5.2) GRE Configuration on a Cluster {#Cluster} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/Cluster-gre-config202010021451441.png) **Note** - It is possible to configure cluster virtual IP addresses in different subnets than the physical IP addresses of the cluster members. This is helpful if the existing subnet has a shortage of available IP addresses. > > #### Adding a GRE Interface on the Cluster > > > 1. On each Cluster Member, configure a GRE interface in Gaia Portal or in Gaia Clish. > > > > For the "local" ip address parameter, use the cluster member's IP address of the underlying interface (e.g. 192.168.1.2 and 192.168.1.3). > > > > When configuring the GRE tunnel peer, use the virtual IP address of the real interface (e.g. 192.168.1.1) as the remote IP. > > > > **Example**: > > > On Cluster Member 1: > > > > > > `add gre id 1 local 192.168.1.2 remote 192.168.2.1 ttl 255 ip 10.0.0.3 mask 24 peer 10.0.0.2` > > > > > > `save config` > > > > > > On Cluster Member 2: > > > > > > `add gre id 1 local 192.168.1.3 remote 192.168.2.1 ttl 255 ip 10.0.0.4 mask 24 peer 10.0.0.2` > > > > > > `save config` > > 2. On each Cluster Member, configure the applicable nexthop address to be the address of the GRE interface on the opposite end of the tunnel. > > > > 3. In SmartConsole, open the Cluster object. > > > > 4. Go to **Network Management**. > > > > 5. Click **Get Interfaces** \> **Get Interfaces with Topology**. > > > > 6. The new GRE interface now appears in the table. Select the GRE interface and click **Edit**. > > > > 7. Change the **Network Type** to **Cluster** and configure the virtual IP address and mask. > > > > 8. Click **OK**. > > > > 9. Install the Access Control Policy on the Cluster. > > #### Deleting a GRE Interface on a Cluster > > > 1. Delete the GRE interface on each Cluster Member in Gaia Portal or in Gaia Clish with this command: > > > > `delete gre id 1` > > > > `save config` > > 2. In SmartConsole, open the Cluster object. > > > > 3. Go to **Network Management**. > > > > 4. Click **Get Interfaces** \> **Get Interfaces with Topology**. > > > > 5. Install the Access Control Policy on the Cluster. ### (5.3) GRE Configuration on a Traditional VSX Gateway {#VSX} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSX-gre-config202010051254311.png) > > #### Adding a GRE Interface on a Traditional VSX Gateway > > > 1. In SmartConsole, configure the VSX Gateway and Virtual System object. > > > > Add the underlying interface of the GRE tunnel to the Virtual System. > > > > In this example, the underlying interface is `eth1`. > > 2. On the command line on the VSX Gateway, add the GRE interface in Gaia Clish: > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 3. In SmartConsole, open the VSX Gateway. > > > > 4. Go to **Physical Interfaces**. > > > > 5. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the id number (example: **gre1**). > > 6. Click **OK**. > > > > 7. Install the Access Control Policy on the VSX Gateway. > > 8. In SmartConsole, open the Virtual System object. > > > > 9. Go to **Topology** \> **Interfaces**. > > > > 10. Click **New**. > > > > 11. In the pop-up window, select the GRE interface. > > > > 12. Configure the IP address and netmask. Set the MTU to **1476.** > > > > 13. Click **OK**. > > > > 14. The Topology should be updated with the new GRE interface. > > > > 15. On the VSX Gateway, configure the applicable nexthop address to be the address of the GRE interface on the opposite end of the tunnel. > > > > 16. Install the Access Control Policy on the Virtual System. > > #### Deleting a GRE Interface on a VSX Gateway > > > 1. In SmartConsole, open the VS object. > > > > 2. Go to **Topology** \> **Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. > > > > 4. Click **OK**. > > > > 5. In SmartConsole, open the VSX Gateway. > > > > 6. Go to **Physical Interfaces**. > > > > 7. Select the GRE interface and click **Remove**. > > > > 8. On the command line on the VSX Gateway, delete the GRE interface in Gaia Clish. > > > > `delete gre id 1` > > > > `save config` ### (5.4) GRE Configuration on a Traditional VSX Gateway with a Virtual Switch {#VSX-VS} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSXwVirtSwitch-gre-config202010051739471.png) > > #### Adding a GRE Interface on a Traditional VSX Gateway with a Virtual Switch > > > 1. In SmartConsole, create a Virtual Switch on the VSX Gateway. > > > > Add the underlying interface of the GRE tunnel to the Virtual Switch. > > > > In this example, the underlying interface is `eth1`. > > 2. In SmartConsole, create a new Virtual System object. > > > > When you define the interfaces on the VS, click **Add** \> **Leads to Virtual Switch**. > > > > Choose the Virtual Switch you just configured and configure the IP address and netmask. > > 3. On the command line on the VSX Gateway, add the GRE interface in Gaia Clish: > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 4. In SmartConsole, open the VSX Gateway. > > > > 5. Go to **Physical Interfaces**. > > > > 6. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the ID number (example: **gre1**). > > 7. Click **OK**. > > > > 8. Install the Access Control Policy on the VSX Gateway. > > 9. In SmartConsole, open the Virtual System object. > > > > 10. Go to **Topology** \> **Interfaces**. > > > > 11. Click **New** \> **Regular**. > > > > 12. In the pop-up window, select the GRE interface. > > > > Configure the IP address and netmask. Set the MTU to **1476**. > > 13. Click **OK**. > > > > 14. The Topology should be updated with the new GRE interface. > > > > 15. On each Gateway, configure the the applicable nexthop address to be > > the address of the GRE interface on the opposite end of the tunnel. > > > > 16. Install the Access Control Policy on the Virtual System. > > #### Deleting a GRE Interface on a Traditional VSX Gateway with a Virtual Switch > > > 1. In SmartConsole, open the Virtual System object. > > > > 2. Go to **Topology** \> **Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. > > > > 4. Click **OK**. > > > > 5. Install the Access Control Policy on the Virtual System. > > 6. In SmartConsole, open the VSX Gateway. > > > > 7. Go to **Physical Interfaces**. > > > > 8. Select the GRE interface and click **Remove**. > > > > 9. On the command line on the VSX Gateway, delete the GRE interface in Gaia Clish: > > > > `delete gre id 1` > > > > `save config` > > 10. Install the Access Control Policy on the VSX Gateway. ### (5.5) GRE Configuration on a Traditional VSX Gateway with a Virtual Router {#VSX-VR} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSX-SingleGW-wVR-gre-config202010081856341.png) > > #### Adding a GRE Interface on a Traditional VSX Gateway with a Virtual Router > > > 1. In SmartConsole, create a Virtual Router on the VSX Gateway. > > > > Add the underlying interface of the GRE tunnel to the Virtual Router. > > > > In this example, the underlying interface is `eth1`. > > > > Configure the IP address and netmask of the interface. > > 2. In SmartConsole, create a new Virtual System object. > > > > When you define the interfaces on the VS, click **Add** \> **Leads to Virtual Router**. > > > > Choose the Virtual Router you just configured and set the IP address and netmask. > > > > The IP address must be routable. > > 3. On the command line on the Security Gateway, add the GRE interface in Gaia Clish: > > > > `add gre id 1 local 20.0.0.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 4. In SmartConsole, open the VSX Gateway object. > > > > 5. Go to **Physical Interfaces**. > > > > 6. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the ID number (example: **gre1**). > > 7. Click **OK**. > > > > 8. Install the Access Control Policy on the VSX Gateway. > > 9. In SmartConsole, open the Virtual System object. > > > > 10. Go to **Topology** \> **Interfaces**. > > > > 11. Click **New** \> **Regular**. > > > > 12. In the pop-up window, select the GRE interface. > > > > Configure the IP address and netmask. > > > > Configure the MTU to **1476**. > > 13. Click **OK**. > > > > 14. Add a default route to the Virtual Router. > > > > Click **Add Default Route** and choose the Virtual Router. > > 15. Click **OK**. > > > > 16. Install the Access Control Policy on the Virtual System. > > #### Deleting a GRE Interface on a Traditional VSX Gateway with a Virtual Router > > > 1. In SmartConsole, open the Virtual System object. > > > > 2. Go to **Topology** \> **Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. > > > > 4. Click **OK**. > > > > 5. Install the Access Control Policy on the Virtual System. > > 6. In SmartConsole, open the VSX Gateway. > > > > 7. Go to **Physical Interfaces**. > > > > 8. Select the GRE interface and click **Remove**. > > > > 9. On the command line on the VSX Gateway, delete the GRE interface in Gaia Clish: > > > > `delete gre id 1` > > > > `save config` > > 10. Install the Access Control Policy on the VSX Gateway. ### (5.6) GRE Configuration on a Traditional VSX Cluster {#VSX-CL} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSX-Cluster-GRE-Config202010081956512.png) > > #### Adding a GRE Interface on a Traditional VSX Cluster > > > 1. In SmartConsole, configure the VSX Cluster and Virtual System. > > > > Add the underlying interface of the GRE tunnel to the Virtual System. > > > > In this example, the underlying interface is `eth1`. > > 2. Install the Access Control Policy - on the VSX Cluster and on the Virtual System. > > > > 3. On the command line on each VSX Cluster Member, add the GRE interface in Gaia Clish: > > > > For the "local" address, use the VIP address of the underlying interface. > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 4. In SmartConsole, open the VSX Cluster object. > > > > 5. Go to **Physical Interfaces**. > > > > 6. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the ID number (example: **gre1**). > > 7. Click **OK**. > > > > 8. Install the Access Control Policy on the VSX Cluster. > > 9. In SmartConsole, open the Virtual System object. > > > > 10. Go to **Topology** \> **Interfaces**. > > > > 11. Click **New**. > > > > 12. In the pop-up window, select the GRE interface. > > > > Configure the IP address and netmask. Set the MTU to **1476**. > > 13. Click **OK**. > > > > 14. The Topology should be updated with the new GRE interface. > > > > 15. Click **OK**. > > > > 16. Install the Access Control Policy on the Virtual System. > > #### Deleting a GRE Interface on a VSX Cluster > > > 1. In SmartConsole, open the Virtual System object. > > > > 2. Go to **Topology** \> **Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. > > > > 4. Click **OK**. > > > > 5. Install the Access Control Policy on the Virtual System. > > 6. In SmartConsole, open the VSX Cluster object. > > > > 7. Go to **Physical Interfaces**. > > > > 8. Select the GRE interface and click **Remove**. > > > > 9. On the command line on each VSX Cluster Member, delete the GRE interface in Gaia Clish: > > > > `delete gre id 1` > > > > `save config` > > 10. Install the Access Control Policy on the VSX Cluster. ### (5.7) GRE Configuration on a VSX Cluster with a Virtual Switch {#VSX-CLVS} These instructions apply to both HA and VSLS environments. ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSXCLwVS-gre-config202010082233221.png) > > #### Adding a GRE Interface on a Traditional VSX Cluster with a Virtual Switch > > > 1. In SmartConsole, create a Virtual Switch and add the underlying interface of the GRE tunnel to the Virtual Switch. > > > > In this example, the underlying interface is `eth1`. > > 2. In SmartConsole, create a new Virtual System. > > > > When you define the interfaces on the Virtual System, click **Add** \> **Leads to Virtual Switch**. > > > > Choose the Virtual Switch you just configured and configure the IP address and netmask. > > 3. Install the Access Control Policy on the Virtual System. > > > > 4. On the command line on each VSX Cluster Member, add the GRE interface in Gaia Clish: > > > > For the "local" address, use the VIP address of the underlying interface. > > > > `add gre id 1 local 192.168.1.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 5. In SmartConsole, open the VSX Cluster. > > > > 6. Go to **Physical Interfaces**. > > > > 7. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the ID number (example: **gre1**). > > 8. Click **OK**. > > > > 9. In SmartConsole, open the VSX Cluster object. > > > > 10. Go to **Topology** \> **Interfaces**. > > > > 11. Click **New** \> **Regular**. > > > > 12. In the pop-up window, select the GRE interface. > > > > Configure the IP address and netmask. Set the MTU to **1476**. > > 13. Click **OK**. > > > > 14. The Topology should be updated with the new GRE interface. > > > > Configure any routes needed for the GRE interface. Click **OK**. > > 15. Install the Access Control Policy on the VSX Cluster. > > #### Deleting a GRE Interface on a Traditional VSX Cluster with a Virtual Switch > > > 1. In SmartConsole, open the Virtual System object. > > > > 2. Go to **Topology** \>**Interfaces**. > > > > 3. Select the GRE interface and click **Delete**. > > > > 4. Click **OK**. > > > > 5. In SmartConsole, open the VSX Cluster. > > > > 6. Go to **Physical Interfaces**. > > > > 7. Select the GRE interface and click **Remove**. > > > > 8. On the command line on each VSX Cluster Member, delete the GRE interface in Gaia Clish: > > > > `delete gre id 1` > > > > `save config` > > 9. Install the Access Control Policy on the VSX Cluster. ### (5.8) GRE Configuration on a Traditional VSX Cluster with a Virtual Router {#VSX-CLVR} ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/VSXwVR-gre-config202010061250201.png) > > #### Adding a GRE Interface on a Traditional VSX Cluster with a Virtual Router > > > 1. In SmartConsole, create a Virtual Router on the Traditional VSX Cluster. > > > > Add the underlying interface of the GRE tunnel to the Virtual Router. > > > > In this example, the underlying interface is `eth1`. > > > > Configure the IP address and netmask of the interface. > > 2. In SmartConsole, create a new Virtual System object. > > > > When you define the interfaces in the Virtual System, click **Add** \> **Leads to Virtual Router**. > > > > Choose the Virtual Router you just configured and set the IP address and netmask. The IP address must be routable. > > 3. Install the Access Control Policy on the Virtual System. > > > > 4. On the command line on each VSX Cluster Member, add the GRE interface in Gaia Clish: > > > > For the "local" address, use the VIP address of the underlying interface. > > > > `add gre id 1 local 20.0.0.1 remote 192.168.2.1 ttl 255 ip 10.0.0.1 mask 24 peer 10.0.0.2` > > > > `save config` > > 5. In SmartConsole, open the VSX Cluster object. > > > > 6. Go to **Physical Interfaces**. > > > > 7. Click **Add** and enter the GRE interface name. > > > > The GRE interface name is **gre** followed by the ID number (example: **gre1**). > > 8. Click **OK**. > > > > 9. In SmartConsole, open the Virtual System object. > > > > 10. Go to **Topology** \> **Interfaces**. > > > > 11. Click **New** \> **Regular**. > > > > 12. In the pop-up window, select the GRE interface. > > > > Configure the IP address and netmask. Set the MTU to **1476**. > > 13. Click **OK**. > > > > 14. Add a default route to the Virtual Router. > > > > Click **Add Default Route** and choose the Virtual Router. > > 15. Click **OK**. > > > > 16. Install the Access Control Policy on the Virtual System. (6) GRE Monitoring using IP Reachability Detection {#Monitoring} ---------------------------------------------------------------- GRE tunnels are stateless by design. However, it is possible to monitor the state of the remote address of the GRE tunnel with IP reachability detection. This monitored address may be further used to dynamically add/remove PBR (policy based routing) or static routes. ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/MonitoringGRE202010082318241.png) This example demonstrates the steps to configure a dynamically added PBR route through two GRE tunnels. > > ### Configuring IP Reachability Detection > > > Configure IP reachability detection on the remote address of the GRE tunnel. > > > > You can monitor it with BFD or ICMP. > > > > In Gaia Portal on the Security Gateway / each Cluster Member, go to **Advanced Routing** \> **IP Reachability Detection** \>**Static Sessions** \> click **Add**. > > > > In this example, we configure IP reachability detection using ping on "Router 1"'s address. > > > > `set ip-reachability-detection ping address 192.168.2.1 enable-ping on` > > > > `save config` > > ### Configuring Dynamic Routing with IP Monitoring > > > A monitored IP configured by IP reachability detection can be used to configure a static route or PBR route. > > > > Multiple next hop gateways can be configured, each with a monitored IP and priority number. > > > > The next hop used by the route is the next hop with the lowest priority number and reachable monitored IP address. > > > > **Warning** - Do not configure multiple next hops with the same priority. > > > > In Gaia Portal on the Security Gateway / each Cluster Member, the option to add a monitored IP address appears when you add a Gateway IP address. > > > > Example: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/IPMonitoring202010082327041.png) > > > > These are the configurations to set up a dynamic PBR route through two GRE tunnels. > > > > * When 192.168.2.1 is reachable, then the nexthop gateway address is 10.0.0.2 (gre1). > > > > * When 192.168.2.1 is not reachable, then the nexthop gateway address is 20.0.0.2 (gre2). > > > > `Clish> show configuration pbr` > > > > `set pbr table gretable static-route 172.16.2.2/32 nexthop gateway address 10.0.0.2 priority 1` > > > > `set pbr table gretable static-route 172.16.2.2/32 nexthop gateway address 10.0.0.2 monitored-ip 192.168.2.1 on` > > > > `set pbr table gretable static-route 172.16.2.2/32 nexthop gateway address 10.0.0.2 monitored-ip-option fail-any` > > > > `set pbr table gretable static-route 172.16.2.2/32 nexthop gateway address 20.0.0.2 priority 2` > > > > `set pbr rule priority 1 match from 172.16.1.2/32 > > set pbr rule priority 1 match to 172.16.2.2/32` > > > > `set pbr rule priority 1 action table gretable` (7) GRE and Policy Based Routing (PBR) with a Firewall Rule using Updatable Objects {#PBR} ------------------------------------------------------------------------------------------ **Note** - For more detailed information on PBR and Firewall Rule matching, see [sk167135](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk167135). > 1. Run these commands on the Security Gateway / each ClusterXL Member in the Expert mode: > > ``` > dbset process:rtgpbrd:runlevel 4 > dbset process:rtgpbrd:path /bin > dbset process:rtgpbrd t > dbset :save > ``` > > 2. Reboot the Security Gateway / each ClusterXL Member. > > 3. In SmartConsole, from the left navigation pane, click **Security Policies** \> **Access Control**. > > 4. Configure a rule. > > The rule name should start with "**PBR_**". > 5. To configure a rule with an updatable object, click to add a new item in the **Source** or **Destination** columns. > > Select **Import** \> **Updatable Objects** and choose the desired online service providers. > > Example: > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/UpdatableObjects202010091349541.png) > 6. **Optional**: To filter traffic by source port: > > 1. In the **Services \& Applications** column, click to add a new item. > > 2. Add a new **TCP** service. > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/Services202010091400392.png) > 3. Choose a protocol or a destination port. > > 4. On the **Advanced** tab, choose a source port. > > 5. Click **OK.** > > 7. Install the Access Control Policy. > > 8. Log in to Gaia Portal on the Security Gateway / each ClusterXL Member: > > **https://\** > 9. Go to **Advanced Routing** \> **Policy Based Routing** \> **Action Tables** \> click **Add**. > > 10. Fill in the required information in the **Add Policy Table with Static Route** window. > > In the **Add Gateway**, select your GRE interface to configure traffic through it. > > Example: > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk169794/edit-policy202010091422573.png) > 11. Click **Save**. > > 12. Go to **Policy Rules** \> click **Add**. > > 13. Configure the required information: > > 1. In the **Action** section \> **Table**, select the table that you just created. > > 2. In the **Match** section \> **Interface**, select the inbound interface. > > 3. In the **Match** section \> **Firewall Rules**, select your Access Control rule configured in SmartConsole. > > 14. Click **Save**. (8) Troubleshooting on the Security Gateway {#Troubleshooting} -------------------------------------------------------------- > 1. Examine the Gaia database bindings for any duplicate / missing bindings. > > Example: > > ``` > [Expert@Gateway:0]# dbget -arv interface:gre1 > interface:gre1:ipaddr > interface:gre1:ipaddr:10.0.0.53 t > interface:gre1:ipaddr:10.0.0.53:mask 24 > interface:gre1:remote 10.0.0.56 > interface:gre1:state on > ``` > > ``` > [Expert@Gateway:0]# dbget -arv gre > gre:1 t > gre:1:local 5.5.5.53 > gre:1:remote 5.5.5.56 > gre:1:ttl 255 > ``` > > 2. Examine the GRE interface configuration: > > ``` > [Expert@Gateway:0]# ifconfig gre1 > Link encap:UNSPEC HWaddr 05-05-05-35-5F-F7-38-50-00-00-00-00-00-00-00-00 > inet addr:10.0.0.53 P-t-P:10.0.0.56 Mask:255.255.255.0 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:37 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:2220 (2.1 KiB) > ``` > > 3. Examine the GRE tunnel configuration: > > ``` > [Expert@Gateway:0]# ip tunnel show > gre0: gre/ip remote any local any ttl inherit nopmtudisc > gre1: gre/ip remote 5.5.5.56 local 5.5.5.53 ttl 255 > ``` > > 4. Capture the traffic on the underlying interface with the TCPdump tool. > > You should see GRE encapsulated packets. > > In this example, we show a ping packet from 3.3.3.42 to 7.7.7.43. > > It is encapsulated by GRE tunnel IPs 5.5.5.55 to 5.5.5.56. > > ``` > [Expert@Gateway:0]# tcpdump -i eth1 > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes > 09:00:06.783677 IP 5.5.5.55 > 5.5.5.56: GREv0, length 88: IP 3.3.3.42 > 7.7.7.43: ICMP echo request, id 5941, seq 13, length 64 > 09:00:06.784407 IP 5.5.5.56 > 5.5.5.55: GREv0, length 88: IP 7.7.7.43 > 3.3.3.42: ICMP echo reply, id 5941, seq 13, length 64 > ``` > > 5. Capture the traffic with the FW Monitor tool. > > It is encapsulated by GRE with IP protocol 47. > > If the GRE traffic is **not** accelerated by SecureXL: > > ``` > [Expert@Gateway:0]# fw monitor -e "ip_p=47, accept;" -o /var/log/fw_mon.cap > ``` > > If the GRE traffic **is** accelerated by SecureXL: > > ``` > [Expert@Gateway:0]# fw monitor -F "0,0,0,0,47" -o /var/log/fw_mon.cap > ``` > > In this example, we show a ping packet from 3.3.3.42 to 7.7.7.43: > > ``` > [vs_0][fw_2] eth2:i[44]: 3.3.3.42 -> 7.7.7.43 (ICMP) len=84 id=60596 > ICMP: type=8 code=0 echo request id=6504 seq=175 > [vs_0][fw_2] eth2:I[44]: 3.3.3.42 -> 7.7.7.43 (ICMP) len=84 id=60596 > ICMP: type=8 code=0 echo request id=6504 seq=175 > [vs_0][fw_2] gre1:o[44]: 3.3.3.42 -> 7.7.7.43 (ICMP) len=84 id=60596 > ICMP: type=8 code=0 echo request id=6504 seq=175 > [vs_0][fw_2] gre1:O[44]: 3.3.3.42 -> 7.7.7.43 (ICMP) len=84 id=60596 > ICMP: type=8 code=0 echo request id=6504 seq=175 > [vs_0][fw_1] eth1:o[44]: 5.5.5.53 -> 5.5.5.56 (47) len=108 id=19982 > [vs_0][fw_1] eth1:O[44]: 5.5.5.55 -> 5.5.5.56 (47) len=108 id=19982 > [vs_0][fw_1] eth1:i[44]: 5.5.5.56 -> 5.5.5.55 (47) len=108 id=28112 > [vs_0][fw_1] eth1:I[44]: 5.5.5.56 -> 5.5.5.53 (47) len=108 id=28112 > [vs_0][fw_2] gre1:i[44]: 7.7.7.43 -> 3.3.3.42 (ICMP) len=84 id=27575 > ICMP: type=0 code=0 echo reply id=6504 seq=175 > [vs_0][fw_2] gre1:I[44]: 7.7.7.43 -> 3.3.3.42 (ICMP) len=84 id=27575 > ICMP: type=0 code=0 echo reply id=6504 seq=175 > [vs_0][fw_2] eth2:o[44]: 7.7.7.43 -> 3.3.3.42 (ICMP) len=84 id=27575 > ICMP: type=0 code=0 echo reply id=6504 seq=175 > [vs_0][fw_2] eth2:O[44]: 7.7.7.43 -> 3.3.3.42 (ICMP) len=84 id=27575 > ICMP: type=0 code=0 echo reply id=6504 seq=175 > ``` (9) Common Setup Issues {#Issues} --------------------------------- > 1. Check the configuration IP addresses for the GRE interface in Gaia Clish. > > `show configuration gre` > 2. For traffic drops due to Anti-Spoofing, update the interface topology on SmartConsole. > > 1. In SmartConsole, open the Security Gateway / Cluster object. > > 2. Go to **Network Management**. > > 3. Click **Get Interfaces** \> **Get Interfaces with Topology**. > > 3. In Traditional VSX setups, add the underlying interface to the Virtual System object and install the Access Control policy before you create the GRE interface. (10) GRE Limitations {#Limitations} ----------------------------------- > Enter the string to filter this table: > > |----------------------------------------------------------|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------|-------------| > | Category | Issue ID | Limitation Description | Reported In | Resolved In | > | Scalable Platforms | MBS-4098, PMTR-60868 | Scalable Platforms (Maestro, Chassis, ElasticXL) do not support GRE interfaces. | R81 | - | > | SecureXL User Mode (UPPAK) | PMTR-112848 | GRE interfaces are not supported in SecureXL User Mode (UPPAK). SecureXL Kernel Mode (KPPAK) supports GRE interfaces but does not accelerate traffic that passes through these interfaces. | R81 | R82.10 | > | Security Gateway as source or destination of GRE packets | PMTR-112848 | SecureXL does not accelerate GRE packets that are terminating or originating on the Security Gateway. | R81 | R82.10 | > | NAT for GRE passthrough traffic | - | SecureXL does not accelerate passthrough GRE packets that are NATed by the Security Gateway. **Note** - For R82 and above, [Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) to get a Hotfix for this issue. | R81 | R82.10 | > | NAT for GRE terminating traffic | - | SecureXL does not accelerate terminating GRE packets that are NATed by the Security Gateway. | R81 | - | > | GRE Tap mode | - | GRE Tap mode is not supported. GRE Tap is a mode in which OSI Layer 2 traffic is encapsulated. | R81 | - | > | IPv6 over GRE | - | IPv6 over GRE is not supported. | R81 | - | > | GRE inspection | - | Security Gateway does not inspect GRE packets that pass through the Security Gateway. Security Gateway only inspects these GRE packets: * That the Security Gateway sends as the source. * That the Security Gateway receives as the destination. If the GRE tunnel does not terminate on the Security Gateway, the inner packet is not inspected. The Access Control rules only apply to the outer packet. | R81 | - | > | GRE monitoring | - | GRE tunnels are stateless by design. For monitoring, check the "GRE Monitoring using IP Reachability Detection" section. | R81 | - | > | CoreXL SND Instances | - | The NIC driver of the underlying interface is responsible for the RSS hash calculation that will determine the SND distribution. For GRE tunnels created over interfaces that use the `igb` or `ixgbe` driver, traffic is not be distributed over multiple CPU cores. With `igb` and `ixgbe` drivers, the RSS hash is calculated by external IP addresses, which are static due to GRE encapsulation. Therefore, based on the RSS hash, all packets go to one CPU core. On the other hand, the `i40e` driver has support for calculating the RSS hash based on inner IP addresses, so traffic is distributed evenly between CPU cores. | R81 | - | > | CoreXL Firewall Instances | - | Traffic in a single GRE tunnel cannot be distributed to multiple CoreXL Firewall instances. The maximum throughput of a single GRE tunnel is limited to throughput handled by a single CoreXL Firewall instance. | R81 | - | > | ClusterXL | - | In ClusterXL, if all cluster members are rebooted simultaneously, GRE traffic may not pass after boot. See [sk169672](https://support.checkpoint.com/results/sk/sk169672). | R81 | R81.10 | > | tcpdump | - | The "`tcpdump -i `" command does not show GRE traffic. Capture traffic on the underlying physical interface of the GRE tunnel. | R81 | - | > | VTI | - | GRE over VTI is not supported when both the VTI and GRE tunnel terminate on the same GW. | R81 | - | > | 3900 appliances | PMTR-112848 | On the 3900 appliances, if in addition to the default Firewall Software Blade, you enable other Software Blades in the Security Gateway / Cluster object, then GRE traffic terminating on the Security Gateway will not work. | R82.10 for 3900 | - | > | 3900 appliances | PMTR-114940 | On the 3900 appliances, GRE over VPN is not supported. It is not supported to initiate encapsulation of GRE tunnel traffic from the Security Gateway and send it over a VPN tunnel. | R82.10 for 3900 | - | > {#GRE_LimitationsTable} --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content