Changes

* Below are explanations of the parameters highlighted in the figure above. Other parameters (not highlighted) are defaults. You can find descriptions for these parameters in the '''[[VPN#GRE Tunnel|VPN manual page, GRE Tunnel section]]'''

* Below are explanations of the parameters highlighted in the figure above. Other parameters (not highlighted) are defaults. You can find descriptions for these parameters in the '''[[VPN#GRE Tunnel|VPN manual page, GRE Tunnel section]]'''

** '''Enable''' - enables the GRE Tunnel instance

** '''Enable''' - enables the GRE Tunnel instance

** '''Remote endpoint IP address''' - the Public IP address of the opposite router

** '''Remote endpoint IP address''' - the Public IP address of the opposite router

** '''Remote network''' - LAN IP address of the opposite router. This and Remote network netmask are used for '''remote LAN access'''

** '''Outbound and Inbound key''' - 65000 (must match other device's Inbound/Outbound key)

** '''Remote network netmask''' - subnet mask of the opposite router's LAN

** '''Local tunnel IP''' - virtual IP address the GRE Tunnel instance (make sure it is '''unique''' for each instance)

** '''Enable Keep alive''' - enables the tunnel's keep alive function. When enabled, the instance sends ICMP packets to the specified host at the specified frequency. If no response is received, the instance attempts to restart the connection

** '''Enable Keep alive''' - enables the tunnel's keep alive function. When enabled, the instance sends ICMP packets to the specified host at the specified frequency. If no response is received, the instance attempts to restart the connection

*** '''Keep alive Host''' - hostname or IP address to which Keep alive packets will be sent to. Best to use a hostname/IP address belonging to the opposite instance's LAN. For this example, we just use the other router's LAN IP address

*** '''Keep alive interval''' - the period (in seconds) at which Keep alive packets will be sent to the specified host in this example 200.

*** '''Keep alive interval''' - the period (in seconds) at which Keep alive packets will be sent to the specified host

** '''Local GRE interface IP address''' - virtual IP address the GRE Tunnel instance (make sure it is '''unique''' for each instance)

** '''Local GRE interface netmask''' - subnet mask of the local GRE Tunnel

** '''Remote subnet IP address''' - LAN IP address of opposite router

** '''Remote subnet IP address''' - Netmask of opposite router

'''NOTE''': remember to replace certain parameter values (like IP addresses) with your own relevant data.

'''NOTE''': remember to replace certain parameter values (like IP addresses) with your own relevant data.

==Testing the setup==

==Testing the setup==

If you've followed all the steps presented above, your configuration should be finished. But as with any other configuration, it is always wise to test the setup in order to make sure that it works properly. In order to test a GRE Tunnel connection, login to one of the routers' WebUIs and go to '''Services → CLI'''. Login with the user name: '''root''' and the router's admin password. From there you should then be able to '''ping''' the opposite instance's virtual IP address. To use a ping command, type '''ping <ip_address>''' and press the "Enter" key on your keyboard:

If you've followed all the steps presented above, your configuration should be finished. But as with any other configuration, it is always wise to test the setup in order to make sure that it works properly. In order to test a GRE Tunnel connection, log in to one of the routers' WebUIs and go to '''Services → CLI'''. Log in with the user name: '''root''' and the router's admin password. From there you should then be able to '''ping''' the opposite instance's virtual IP address. To use a ping command, type '''ping <ip_address>''' and press the "Enter" key on your keyboard:

[[File:Configuration example ipsec testing.png]]

[[File:Networking rutxxx configuration examples ping to gre client v1.jpg|border|class=tlt-border]]

You can also test if LAN access is working the same way. Instead of pinging the opposite instance's LAN IP address, ping one of the end devices' IPs. One common issue that can be encountered here is that the end devices '''might need their DHCP leases renewed'''. There are many methods of accomplishing this, but the easiest and most accessible way is to simply disconnect and reconnect the LAN cable to the device or the router that it's connected to.

You can also test if LAN access is working the same way. Instead of pinging the opposite instance's LAN IP address, ping one of the end devices' IPs. One common issue that can be encountered here is that the end devices '''might need their DHCP leases renewed'''. There are many methods of accomplishing this, but the easiest and most accessible way is to simply disconnect and reconnect the LAN cable to the device or the router that it's connected to.

* Other types of VPNs suported by RUTxxx devices:

* Other types of VPNs suported by RUTxxx devices:

** [[OpenVPN configuration examples]]

**[[OpenVPN configuration examples RUT R 00.07|OpenVPN configuration examples]]

** [[IPsec configuration examples]]

** [[IPsec RUTOS configuration example|IPsec configuration examples]]

** [[PPTP configuration examples]]

** [[PPTP configuration examples RutOS|PPTP configuration examples]]

** [[L2TP configuration examples]]

** [[L2TP configuration examples RutOS|L2TP configuration examples]]