Before you start
GRE tunneling technology was added in NSX 6.4. This technology is implemented with minimal functionality, IPSec and OSPF services do not recognize GRE interfaces, as well as there is no implementation of logging and monitoring, except for simple ping. Currently, GRE tunnels can be created only by NSX administrators via Rest API. VCloud users can't use this feature.
However, VMWare has implemented the creation of encrypted tunnels via Route-Based IPSec VPN (VTI over IPSec). This technology is identical to Generic Routing Encapsulation (GRE) over IPSec, except that no additional encapsulation is added to the packet before IPSec processing is applied. The table below shows which vendors support this feature. The difference from normal GRE is in encapsulation methods - VTI saves 4 bytes by eliminating the GRE header.
| Vendor | Route-Based IPSec VPN support |
|---|---|
| Cisco | yes |
| Juniper | yes |
| Mikrotik | no |
Introduction
The goal of the original problem is to achieve fault tolerance under the scheme when two encrypted tunnels are created from a remote OFFICE on the same channel to two Edge (EDGE-2 and EDGE-3) located in different data centers but connected by L2 line. You can see the scheme below.
We need to configure the infrastructure so that if the connection between the OFFICE and one of the EDGE is lost, we can maintain the availability of infrastructure located in subnets 10.20.20.0/29 and 10.100.100.0/29. In order to do this, you must follow these steps:
- Deploy the infrastructure in each VDC (networks, vApp, VM)
- Create Route-Based IPSec VPN tunnels between nodes OFFICE-EDGE-2 and OFFICE-EDGE-3
- On nodes, EDGE-2 and EDGE-3, create static routes over GRE to OFFICE.
- On the OFFICE node, create static routes to EDGE-2 and EDGE-3
- Test the created infrastructure for availability.
- Fix the availability of all nodes in the scheme by turning off one of the tunnels.
For ergonomic perception, all screenshots of all nodes will be marked with color according to the mask:
OFFICE - 45.134.62.220
EDGE-2 - 176.53.182.220
EDGE-3 - 176.53.182.209
The Office node is represented in this article on EDGE, but you can configure any supported device to build this scheme.
Also, to reduce the amount of information, the duplication of screenshots from the same nodes will be minimized.
Preparing the infrastructure
- Create vApp (VAPP_TWO) and VM (VM-EDGE-2) in VDC. Do the same for other nodes.
Create an EDGE-2 LAN 10.100.100.0/29 and connect it to EDGE-2. Do the same for EDGE-3 (LAN-EDGE-3 10.20.20.0/29) and for Office (192.168.10.0/29)
- Go to EDGE>VPN>IPSec settings and choose to create IPsec VPN Sites
- Create Route-Based IPSec according to the matrix of all three nodes (on the Office side you must configure two tunnels, one to each EDGE node):
| Parameter | EDGE-3 | EDGE-2 | OFFICE |
| Name | TO Office |
To Office |
To EDGE-1, To EDGE-2 |
| Local ID | 176.53.182.220 | 45.134.62.220 | 176.53.182.209 |
| Peer Subnets | 0.0.0.0/0 | 0.0.0.0/0 | 0.0.0.0/0 |
| Encryption Algorithm | AES-256 | AES-256 | AES-256 |
| Peer Subnets | 0.0.0.0/0 | 0.0.0.0/0 | 0.0.0.0/0 |
| Encryption Algorithm | AES-256 | AES-256 | AES-256 |
| Authentication | PSK | PSK | PSK |
| Pre-Shared Key | *** | *** | *** |
| Diffie-Hellman Group | DH14 | DH14 | DH14 |
| Digest Algorithm | SHA-256 | SHA-256 | SHA-256 |
| IKE Option | iKEv-2 | iKEv-2 | iKEv-2 |
| Session Type | Route-Based Session | Route-Based Session | Route-Based Session |
| Tunnel Interface IP CIDR | 172.16.0.2/30 | 172.10.0.2/30 | 172.16.0.1/30, 172.10.0.1/30 |
| Tunnel Interface MTU | 1500 | 1500 | 1500 |
- Configure static routes between the created tunnels on each node.
| SOURCE | NETWORK | NEXT HOP | DISTANCE |
|---|---|---|---|
| EDGE-3 to EDGE-2 (L2) | 10.100.100.0/29 | 192.168.3.102 | 1 |
| EDGE-3 to Office (VTI) | 192.168.10.0/29 | 172.10.0.1 | 1 |
| EDGE-3 to Office через EDGE-2 |
192.168.10.0/29 |
192.168.3.102 |
2 |
| EDGE-2 to EDGE-3 (L2) | 10.20.20.0/29 | 192.168.3.101 | 1 |
| EDGE-2 to Office (VTI) | 192.168.10.0/29 | 172.16.0.1 | 1 |
| EDGE-2 to Office через EDGE-3 |
192.168.10.0/29 |
192.168.3.101 |
2 |
When creating the Static Routes, in the Network field specify the subnet behind the opposite node. In the Next Hop field, specify the IP address of the IPSec tunnel of the opposite node.
- From the Office node, record the availability of subnets connected to EDGE-2 and EDGE-3
- Fix the traffic to subnets via the created tunnels
Checking availability after the tunnel has been disconnected
- With all hosts logically connected, we need to disable the tunnel on the Office > EDGE-2 (172.16.0.0/30) route to verify that the route to the subnet behind EDGE-2 goes through EDGE-3. To do this, disable the IPSec VTI tunnel on the EDGE-2 host.
2. Now note that the subnet on EDGE-2 remains accessible, but via a route through the EDGE-3 node.
- Similarly, check the availability of Office from EDGE-2
As you can see, the availability of the node is maintained, hence the fault tolerance is fixed.
