In addition to supporting OpenVPN site-to-site and plain IPsec site-to-site, you may also wish to run a tunneling protocol over an IPsec site-to-site connection, such as GRE, IP in IP, etc. The advantage of this over just using a plain site-to-site IPsec tunnel is that the tunnel gets associated with a dedicated interface (usually tun0 or similar), whereas "plain" IPsec does not create a dedicated interface for the tunnel and instead peers with a specified address.

Note: for the remainder of this article, unless otherwise specified, we will be using GRE as our encapsulation protocol.

There are effectively three ways of structuring such a secure tunnel:

The configuration differences between the three are minimal, and the bulk of the setup is for IPsec itself.

The first solution is simple, but comes with a couple of caveats:

The second solution requires a little bit more setup, but only allows for communication over IPsec. The use of a dummy address as the source IP means this solution solves the dynamic address/NAT problems of the simple solution, but does come with a few downfalls itself:

The third solution, using a VTI, is slightly outside of the scope of this article, and will be covered in a future article. However, VTIs are essentially IPIP tunnel interfaces that get bound to IPsec connections, solving the first solution's issue of potentially sending unencrypted traffic should the IPsec connection fail. They are (marginally) easier to set up than the loopback device, but don't allow the choice of the encapsulation protocol.

For further reading on the difference between these methods, check out this entry on the VyOS blog: On security of GRE/IPsec scenarios.

Configuration Using Just GRE/IPsec

Assuming we know both routers have a static IP, are not NATed, the configuration for GRE over IPsec (or, again, any other encapsulation protocol) is relatively simple, only requiring a few more configuration entries over the plain IPsec site-to-site configuration.

Topologies

This configuration is based off of the one detailed in the above linked IPsec site-to-site VPN article, and assumes the same names and addresses:

For central-office-net: 

For remote-office-net: 

Like the other config, we will be using the pre-shared secret method for authentication; the key is not-so-secret. 

Configuration of central-office-rtr:

Firstly, we need to set up a GRE tunnel:

IPsec configuration follows the other example exactly until specifying the tunnel. Instead of running the set vpn ipsec peer tunnel commands in the plain IPsec example article, run this instead:

This tells IPsec to encrypt the GRE traffic between the two networks.

The full IPsec example configuration looks like this (from the vpn ipsec configuration tree:

Essentially the same as central-office-rtr  with the appropriate addresses changed:

Similarly for IPsec: 

 There should now be a functioning GRE tunnel between the two routers that is encrypted using IPsec. 

Configuring GRE/IPsec Using a Loopback Interface

We will be using the same network setup from above, except that we no longer know the public IP address of remote-office-net. As a result, we have to use VyOS' feature of IDs in lieu of remote addresses, which also requires us to use RSA or X.509 authentication. We will be using RSA for this example.

Additionally,  we will be using the dummy interface dum0 on both routers as our loopback interface, and central-office-rtr will have the address 192.168.1.100 for its dummy interface, and remote-office-rtr will use 192.168.1.200.

This VyOS blog entry may also be of interest: How to setup an IPsec connection between two NATed peers: using id's and RSA keys.

Generate RSA Keys on Both Routers: 

The IPsec setup is a little bit more complicated. Because we have to use IDs instead of IP addresses for the remote address, we'll also have to set up our preferred authentication method (either RSA or X.509 certificates; we'll be using RSA) instead of using a pre-shared secret. For RSA, we have to generate a key pair on both routers. This is done from operational mode with the command: 

 We also need a key from the remote office:

(You may also use a 2048 bit key)
This should result in the public key being printed to the screen (typically starting with 0sAQ...). This key will need to be added on remote-office-rtr. Similarly, the public key generated by remote-office-rtr will need to be added to central-office-rtr.

You may import a key on either host through the command:

where is the name of the key (typically, and in our case, the name of the system the key is from), and is the public key string from that machine that was printed when it was made. Importing the keys will be shown in the configuration example for both routers below, which assumes we have generated a key on both routers. 

Firstly, we have to make our loopback device and configure our tunnel appropriately:

Now, we need to import the key we generated earlier on the Remote office's router:

(RSA key truncated for brevity) 

And now to set up IPsec itself:
(Note: we'll be using the same ike-group and esp-group names and settings as the previous configuration example above.) Because the remote office has a dynamic or unknown public IP, we'll need to use an ID for the peer name. The ID can be any string, as long as it's prefixed with an @ symbol. It's essentially a stand-in for an IP address that's useful for when we do not know the exact address of a particular host. 

The last two lines are to use the dummy interface addresses for the tunnel.

Setting up the dummy interface and tunnel on the remote router:

Import the key from central-office-rtr: 

And now setup IPsec:

Your tunnel should now be setup properly.

The key difference between this and the previous setup is that, due to lack of known address on one end, we have to use the additional configuration option connection-type. This way, the router setup with the initiate connection type will start the connection (since it knows the static IP of the other router) and the other router can then respond to it. We also must specify the ID used for the remote office on central-office-rtr in the authentication parameters on the remote-office-rtr itself.